Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 2 years ago

Closed 17 months ago

Last modified 9 months ago

#10732 closed Bug Report - General (Fixed)

Recordings fail after upgrade to .25

Reported by: daveshome@… Owned by: danielk
Priority: minor Milestone: 0.26.1
Component: MythTV - Recording Version: 0.25-fixes
Severity: medium Keywords:
Cc: Ticket locked: yes

Description (last modified by wagnerrp)

Working fine for years but since the upgrade to .25 I have been getting recording not found errors when trying to watch a show. They show up in the listing but are empty and the files do not exist on the HD. I see a lot of this in the logs.
I have tried removing all the devices and re-adding again. No difference. A reboot gets things working for a little while but it comes back.

May 17 02:09:59 mythserver mythbackend[1626]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
May 17 02:09:59 mythserver mythbackend[1626]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
May 17 02:10:01 mythserver mythbackend[1626]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video1): Poll giving up 2
May 17 02:10:01 mythserver mythbackend[1626]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video1): Device error detected
May 17 02:10:04 mythserver mythbackend[1626]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
May 17 02:10:04 mythserver mythbackend[1626]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
May 17 02:10:06 mythserver mythbackend[1626]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video1): Poll giving up 2
May 17 02:10:06 mythserver mythbackend[1626]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video1): Device error detected
May 17 02:10:09 mythserver mythbackend[1626]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
May 17 02:10:09 mythserver mythbackend[1626]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
May 17 02:10:11 mythserver mythbackend[1626]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video1): Poll giving up 2
May 17 02:10:11 mythserver mythbackend[1626]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video1): Device error detected
May 17 02:10:14 mythserver mythbackend[1626]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
May 17 02:10:14 mythserver mythbackend[1626]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
May 17 02:10:16 mythserver mythbackend[1626]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video1): Poll giving up 2
May 17 02:10:16 mythserver mythbackend[1626]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video1): Device error detected

Attachments (4)

debug.txt (61.4 KB) - added by anonymous 2 years ago.
mythbackend.20120528005027.4249.Debug.log (158.6 KB) - added by SBMythTV@… 2 years ago.
mythbackend log with -v record,channel settings (Kenan Ezal)
debug.2.txt (12.0 KB) - added by Michael Harnden <mike@…> 23 months ago.
Backend and Kernel logs of latest failure
DeviceReadBuffer.cpp-patch (4.5 KB) - added by ltskinol@… 19 months ago.

Download all attachments as: .zip

Change History (52)

comment:1 Changed 2 years ago by wagnerrp

  • Description modified (diff)
  • Milestone changed from 0.25.1 to unknown
  • Priority changed from critical to minor

comment:2 Changed 2 years ago by wagnerrp

  • Component changed from MythTV - General to MythTV - Recording
  • Owner set to danielk

comment:3 Changed 2 years ago by danielk

  • Status changed from new to infoneeded_new

Please attach a "mythbackend -v record,channel" log for the entire debugging session.

comment:4 Changed 2 years ago by daveshome@…

debug file attached. Started with mythbackend -v record,channel

Kicked off three recordings through mythweb.
Checked status on mythweb
saw 2 were failing.
Deleted shows through mythweb.
stopped debug.

Changed 2 years ago by anonymous

comment:5 Changed 2 years ago by daveshome@…

Any ideas on what I can try or test. Wife is getting pissed that her recordings are failing. lol.

Is it possible to downgrade and keep settings or would the database cause issues.

Others seem to be having this problem as well.
http://www.mythtv.org/pipermail/mythtv-users/2012-May/333348.html

Changed 2 years ago by SBMythTV@…

mythbackend log with -v record,channel settings (Kenan Ezal)

comment:6 Changed 2 years ago by SBMythTV@…

I just attached my log with -v record,channel options on.

The debug session started last night around 1am. During the log I deleted a couple of shows and three shows for my kids recorded in the morning. Error messages appear during these recordings, but the recordings are successful from the point that I can play them back.

It isn't until 1800 hours when the news is recorded that a recording actually fails. At this point error messages repeat for an entire hour. I've deleted most of the redundant error messages to minimize the file size. Then at 9pm another recording starts but is a failed recording since the tuner is in a 'bad' state from before. It is necessary to reboot to get the system back into a good state.

My system currently has a PVR-150 on the master backend and a PVR-350 on the slave backend. Although the slave backend was also recording at 1800 hours, this is simply coincidence. I have made the recordings fail when there is only one recording going on at the same time. I have successfully failed recordings for PVR-150, 250, and 350, whether or not the tuner is on the master backend (64-bit Fedora 16) or the slave backend (32-bit Fedora 16).

I was not having any problems prior to upgrading to 0.25.

I appreciate all the hard work put into Myth. Please let me know if I can help out in any other way.

-Kenan Ezal (SBMythTV)

comment:7 Changed 2 years ago by kenni

  • Status changed from infoneeded_new to new

Requested logs provided by two users.

comment:8 Changed 23 months ago by michael.harnden@…

I am having the same issues. They started upon upgrading to 0.25 with no other changes. Since then I have upgrade to Mythbuntu 12.04.

As a workaround, I have been unloading/loading the ivtv modules via cron job.
modprobe -r ivtv
modprobe ivtv debug=0x4f

I'll log of latest failure. In my logs /dev/video0 (ivtv0) is a PVR350 recording via SVideo and /dev/video1 (ivtv1) is a PVR150 connect via coax.
Mike

Changed 23 months ago by Michael Harnden <mike@…>

Backend and Kernel logs of latest failure

comment:9 Changed 23 months ago by mamochan@…

I have suffered this fault as well and have had massive success by changing the mythbackend IO priority from idle to realtime.

Command to change IOPriority to realtime:
ionice -c1 -n0 -p $(pidof mythbackend)

comment:10 Changed 23 months ago by daveshome@…

mamochan: Awesome. I had been scheduling reboots twice a day using the mythshutdown script to try to avoid these failed recordings. Then I had been loading and unloading the ivtv drivers with a cron job instead. Both sort of worked but I still had some fails.

Increasing the priority as you posted seems to be working. I haven't had a failed recording in a couple of days now.
Thanks for this tip.

comment:11 Changed 22 months ago by anonymousdog@…

I have obtained similar results with 'ionice -c2 n0 -p $(pidof mythbackend)' which seems less heavy-handed since it's (the highest priority in the) "best effort" class instead of the "real time" class. I have managed to evoke failed channel changes (ending in "Error opening jump program file" message) in LiveTV once or twice in a couple of weeks, but no scheduled recordings have failed (or resulted in 0-byte files).

comment:12 Changed 21 months ago by anonymousdog@…

This issue persists despite the above hack. Though symptoms are much reduced, LiveTV, in particular, can still elicit these symptoms. Also BE service restarts while a scheduled recording is in progress temporarily result in two BE instances running (for <10s) that probably compete for the tuner and almost always results in a zero byte file and at least of of those BE instances needing 'kill -9' before a clean BE instance can be started. I'm moving to realtime:0 for testing now, but I strongly believe this hack just masks a significant issue with IVTV support in 0.25...I am on Mythbuntu repos nightly builds, BTW...so only about a day behind commits on 0.25.1 fixes.

comment:13 Changed 21 months ago by anonymyth@…

I am having the exact same symptoms since I upgraded from 0.24 to 0.25 three weeks ago. I have three PVR-150s and all three have been involved at different times, so I don't think its a HW problem. Thanks, John

comment:14 follow-up: Changed 21 months ago by anonymyth@…

I am having the exact same symptoms since I upgraded from 0.24 to 0.25 three weeks ago. I have three PVR-150s and all three have been involved at different times, so I don't think its a HW problem. Thanks, John

comment:15 Changed 21 months ago by soul-mates@…

I am also seeing this, although the recordings that are failing are on DVB-T tuners.
I do have a PVR150 and PVR500 in the Backend, but these are only used for occasional composite input recording (converting videos to digital)
The ionice hack definitely reduces the problem.
openSUSE 12.1, Mythtv 0.25-fixes (from Packman rpm)

My problems started with an upgrade from 0.24 to 0.25

comment:16 follow-up: Changed 21 months ago by danielk

  • Status changed from new to infoneeded_new

Was the Linux kernel also upgraded?

comment:17 in reply to: ↑ 14 Changed 21 months ago by anonymyth@…

Replying to anonymyth@…:

I am having the exact same symptoms since I upgraded from 0.24 to 0.25 three weeks ago. I have three PVR-150s and all three have been involved at different times, so I don't think its a HW problem. Thanks, John

In my case I upgraded Ubuntu 10.04 to 12.10. I was on kernel 2.6.38-8 and am now on 3.2.0-27.

comment:18 Changed 21 months ago by SBMythTV@…

When I upgraded MythTV from 0.24 to 0.25 I also upgraded to the latest kernel at that time (under Fedora 16). I have since down-graded MythTV from 0.25 to 0.24 and everything is working fine. So it wasn't the kernel alone causing the problems. I can find out the specific kernel when I go back home tonight. I don't recall at this time. I have not changed my system since that time (early June 2012), and the only change I made to my system was to down-grade MythTV to 0.24.

comment:19 in reply to: ↑ 16 Changed 21 months ago by Michael Harnden <michael.harnden@…>

Replying to danielk:

Was the Linux kernel also upgraded?

In my case not initially. The problems surfaced after only upgrading MythTV to 0.25 from 0.24. After I started having problems, I updated the kernel to try and mitigate the problems.

comment:20 Changed 21 months ago by danielk

  • Status changed from infoneeded_new to assigned

comment:21 Changed 21 months ago by anonymousdog@…

Same here: problem initially noted on a MythTV upgrade from 0.23 to 0.25 on Mythbuntu 10.04...no kernel change. Symptoms are improved but not eliminated with the ionice hack (whether besteffort:0 or realtime:0). LiveTV seems more likely to elicit symptoms than scheduled recordings, but those have failed too.

comment:22 Changed 21 months ago by danielk

The ionice hack should really have no effect on recording. There are multiple buffers between the recording hardware and writing to disk. There is a device reading thread with a buffer + file writing thread with a buffer.

BTW if you have dedicated recording drives it's better to use the deadline scheduler than cfq (ionice only works with the cfq scheduler).

Use something like this in your rc.local:

echo deadline > /sys/block/sda/queue/scheduler
echo 1 > /sys/block/sda/queue/iosched/fifo_batch

Can you attach a log where it the symptoms are "reduced" ?

comment:23 Changed 21 months ago by anonymousdog@…

I don't know WHY the ionice tweak works, but it most definitely works. I'd estimate it reduces symptom frequency by at least one order of magnitude.

I'll try to catch logs of the next failure of a scheduled recording.

This is the interesting bit of a LiveTV occurrence (regular BE logging):

Aug  2 10:04:29 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Playback
Aug  2 10:04:29 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv as a client (events: 0)
Aug  2 10:04:29 mythtv mythbackend[11323]: I TVRecEvent tv_rec.cpp:1029 (HandleStateChange) TVRec(1): Changing from None to WatchingLiveTV
Aug  2 10:04:29 mythtv mythbackend[11323]: I TVRecEvent mythdbcon.cpp:395 (PurgeIdleConnections) New DB connection, total: 11
Aug  2 10:04:29 mythtv mythbackend[11323]: I TVRecEvent tv_rec.cpp:3495 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
Aug  2 10:04:29 mythtv mythbackend[11323]: I TVRecEvent v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
Aug  2 10:04:29 mythtv mythbackend[11323]: N CoreContext autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 21.0 GB w/freq: 15 min
Aug  2 10:04:31 mythtv mythbackend[11323]: N CoreContext autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 21.0 GB w/freq: 15 min
Aug  2 10:04:33 mythtv mythbackend[11323]: W RecThread mpegrecorder.cpp:1315 (StartEncoding) MPEGRec(/dev/video0): StartEncoding failed#012#011#011#011eno: Input/output error (5)

After that attempts to use the tuner result in poll errors, and the FE interface will claim the tuner is busy (even though the system info screen shows it idle).

comment:24 Changed 21 months ago by anonymousdog@…

I found a scheduled recording...

Aug  1 18:59:00 mythtv mythbackend[11323]: I TVRecEvent tv_rec.cpp:1536 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 28 0 0
Aug  1 18:59:30 mythtv mythbackend[11323]: I TVRecEvent tv_rec.cpp:1029 (HandleStateChange) TVRec(1): Changing from None to RecordingOnly
Aug  1 18:59:30 mythtv mythbackend[11323]: I TVRecEvent mythdbcon.cpp:395 (PurgeIdleConnections) New DB connection, total: 9
Aug  1 18:59:30 mythtv mythbackend[11323]: I TVRecEvent tv_rec.cpp:3495 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
Aug  1 18:59:30 mythtv mythbackend[11323]: I CoreContext mythdbcon.cpp:395 (PurgeIdleConnections) New DB connection, total: 9
Aug  1 18:59:30 mythtv mythbackend[11323]: I TVRecEvent v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
Aug  1 18:59:30 mythtv mythbackend[11323]: N Scheduler autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 21.0 GB w/freq: 15 min
Aug  1 18:59:30 mythtv mythbackend[11323]: I Scheduler scheduler.cpp:2514 (HandleRecordingStatusChange) Tuning recording: "The Mentalist":"Red John's Footsteps": channel 1138 on cardid 1, sourceid 1
Aug  1 18:59:32 mythtv mythbackend[11323]: I CoreContext scheduler.cpp:637 (UpdateRecStatus) Updating status for "The Mentalist":"Red John's Footsteps" on cardid 1 (Tuning => Recording)
Aug  1 18:59:32 mythtv mythbackend[11323]: I TVRecEvent tv_rec.cpp:3989 (TuningNewRecorder) TVRec(1): rec->GetPathname(): '/var/lib/mythtv/recordings/1138_20120801190000.mpg'
Aug  1 18:59:33 mythtv mythbackend[11323]: W RecThread mpegrecorder.cpp:1315 (StartEncoding) MPEGRec(/dev/video0): StartEncoding failed#012#011#011#011eno: Input/output error (5)
Aug  1 19:00:26 mythtv mythbackend[11323]: E DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
Aug  1 19:00:26 mythtv mythbackend[11323]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected

At the end of that episode, the commflagging not finding the file (I think)...

Aug  1 20:00:00 mythtv mythbackend[11323]: I RecThread tv_rec.cpp:3292 (RingBuff
erChanged) TVRec(1): RingBufferChanged()
Aug  1 20:00:00 mythtv mythbackend[11323]: I CoreContext scheduler.cpp:637 (UpdateRecStatus) Updating status for "The Mentalist":"Red John's Footsteps" on cardid 1 (Recording => Recorded)
Aug  1 20:00:00 mythtv mythbackend[11323]: I RecThread recordinginfo.cpp:1113 (FinishedRecording) Finished recording The Mentalist "Red John's Footsteps": channel 1138
Aug  1 20:00:00 mythtv mythbackend[11323]: I Scheduler scheduler.cpp:2033 (HandleReschedule) Reschedule requested for id 0.
Aug  1 20:00:03 mythtv mythbackend[11323]: I Scheduler scheduler.cpp:2093 (HandleReschedule) Scheduled 498 items in 2.9 = 0.00 match + 2.92 place
Aug  1 20:00:43 mythtv mythbackend[11323]: I Commflag_14620 jobqueue.cpp:2276 (DoFlagCommercialsThread) JobQueue: Commercial Detection Starting for "The Mentalist":"Red John's Footsteps" recorded from channel 1138 at 2012-08-01T19:00:00
Aug  1 20:00:44 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Monitor
Aug  1 20:00:44 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv as a client (events: 0)
Aug  1 20:00:44 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Monitor
Aug  1 20:00:44 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv as a client (events: 1)
Aug  1 20:01:32 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Playback
Aug  1 20:01:32 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv as a client (events: 0)
Aug  1 20:01:32 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1475 (HandleAnnounce) MainServer::HandleAnnounce FileTransfer
Aug  1 20:01:32 mythtv mythbackend[11323]: I ProcessRequest mainserver.cpp:1477 (HandleAnnounce) adding: mythtv as a remote file transfer
Aug  1 20:01:32 mythtv mythbackend[11323]: W ProcessRequest mainserver.cpp:5801 (connectionClosed) MainServer: Unknown socket closing MythSocket(0x1fa66d0)
Aug  1 20:01:32 mythtv mythbackend[11323]: E ProcessRequest mythsocket.cpp:358 (writeStringList) MythSocket(1fa66d0:-1): writeStringList: Error, socket went unconnected.#012#011#011#011We wrote 0 of 10 bytes with 1 errors#012#011#011#011starts with: 2       ok

comment:25 Changed 20 months ago by vdzenh4673@…

This issue has annoyed me to no end. I've tried all the suggested workarounds to no avail.
A system reboot seems to be the only thing that clears it up for a good stretch before it happens again.
I use the script below to auto reboot when "poll error" is detected in mythbackend.log.
I set it up to run on boot in the background from /etc/runit/1.local

Distro: LinHES 7.4

#!/bin/sh
#
# As root
#
LOG=${1:-/var/log/mythtv/mythbackend.log}
tail -Fn0 $LOG |
while read line ; do
	echo "$line" | egrep -i -q -e "(poll error|poll giving up)"
	rc=$?
	if [ $rc -eq 0 ] ; then
		echo $line
		/sbin/reboot
	fi
done

comment:26 Changed 20 months ago by soul-mates@…

I have solved the problem on my system, as I mentioned earlier (comment 15) I use DVB-T cards for recordings, and I had a PVR150 and a PVR500 installed but not regularly used.
Recordings would fail ever night, on the DVB-T cards, and only a reboot would temporarily fix it.
The ionice hack reduced the frequency to approx 3-5 days between reboots.

I have removed both PVR cards, and have had no issues at all since. 10 days with 0 failed recordings and 0 reboots.

As I no longer need Analog tuners, I am happy that my issues are resolved.

Whatever is causing this seems to be related to the PVR cards or at least their driver.

comment:27 Changed 20 months ago by vdzenh4673@…

Oh well, I give up on 0.25. Too many issues with failed recordings. Wifey reached the threshold of missed daytime soaps. My PVR-500s work just fine under 0.24 so I've rolled back and all is good in Mythdom again. I may slap 0.25 on a spare box to continue the struggle later.

Back to Distro: LinHES 7.2

comment:28 Changed 20 months ago by ted@…

Any news on this bug? Is it possible that this bug is only triggered when two PVR cards are installed? Every comment above reports more than one installed card.

comment:29 Changed 20 months ago by vdzenh4673@…

@ted: I can report that the issue also happens with only one PVR card installed. My spare 0.25 test system has a single PVR-150 and the bug persists.

comment:30 Changed 20 months ago by ted@…

@vdzenh: That's too bad. In that case, is it possible to escalate this ticket above minor priority? The PVR-150 is a very widely used recording device in MythTV, and it's pretty disruptive that it's not working well.

comment:31 Changed 20 months ago by kenni

  • Ticket locked set

Guys, this is not a discussion forum...please read the TicketHowTo.

comment:32 Changed 19 months ago by danielk

  • Ticket locked unset

Changed 19 months ago by ltskinol@…

comment:33 Changed 19 months ago by ltskinol@…

Patch attached.

Changes libs/libmythtv/DeviceReadBuffer.cpp ::Poll as follows:

  • Reorganizes main loop to be clearer, without changing functionality.
  • Always check return from poll() before using the return structures.

This was a bug, though perhaps innocuous.

  • Adds missing lock before setting error=true. This was a bug.
  • Treats a poll() return of POLLHUP as EOF rather than an error.

The last change is what "fixes" the problem. What's happening is that
the ivtv driver returns HUP when an attempt to read at EOF of the
stream. Myth was then interpreting this as an error, and
re-initializing the driver, which wasn't the correct behavior.

Works for me to fix the problem noted in the bug.

I say "fixes" because I think this is just a workaround for a race
condition, but I don't know enough about Myth to debug that. What I
see in the logs is:

2012-10-03 00:05:15.375429 I [9918/9932] TVRecEvent tv_rec.cpp:1029
(HandleStateChange?) - TVRec(4): Changing from RecordingOnly? to None
2012-10-03 00:05:15.690488 E [9918/10107] DeviceReadBuffer?
DeviceReadBuffer?.cpp:490 (Poll) - DevRdB(/dev/video0): poll eof
(POLLHUP)
2012-10-03 00:05:16.039436 E [9918/10105] RecThread?
mpegrecorder.cpp:1017 (run) - MPEGRec(/dev/video0): Device EOF
detected
2012-10-03 00:05:16.200041 I [9918/9918] CoreContext? scheduler.cpp:638
(UpdateRecStatus?) - Updating status for Seinfeld:"The Revenge" on card
id 4 (Recording => Recorded)

At the end of a recording, I usually see one of these POLLHUP errors,
indicating that the Poll() loop read from the device and got an EOF
indication. My theory is that Myth is stopping the recording (and
somehow indicating to ivtv that it needs to stop encoding) but then
has no way of stopping an in-progress system poll() call. So the
poll() returns POLLHUP, indicating that the encoder has gone away.
Seems like the proper fix is to somehow cancel the poll(). My "fix"
just works around the problem by not treating POLLHUP as an error.

comment:34 Changed 17 months ago by George Mari <george@…>

I applied the patch provided by ltskinol. I'm running on Fedora 17, RPMFusion, MythTV version 25.2. I downloaded the source RPMS from RPM Fusion, applied the patch, and simply copied over the new libmythtv.so file that was created. Restarted my MythTV box. Everything came up just fine and has been working for 8 days now, since November 11th.

I have a PVR-350 I use for recording from a DirecTV settop box, and an HVR-2250 for recording OTA here in the Chicago area.

Before this patch, my PVR-350 would fail recordings once every 36 to 48 hours regularly. So far it has been 8 days of successful recordings.

comment:35 Changed 17 months ago by Sean Donovan wiki user:mrsdonovan <sean@…>

I vote this one up - I upgraded to 0.25 last week and have the same problem - both the PVR-150 and PVR-250 now fail most of the time and they worked perfectly with previous versions. Besides a few miscellaneous libraries, MythTV was the only thing I upgraded.

System: Slave backend on Ubuntu 10.04 (2.6.32-27-generic-pae) with three tuners connected via a PVR-150, PVR-250 and a DCT-6200 controlled over firewire. MythTV version is 0.25.3+fixes.20121122.f176258 (hot off the presses! :-( made no difference). Master backend has a HDPVR and is running at the same version of MythTV and it works fine.

On Slave backend with PVR-x50s, I completely uninstalled and reinstalled MythTV and problem persists.

comment:36 follow-up: Changed 17 months ago by Sean Donovan wiki user:mrsdonovan <sean@…>

I have disabled the two PVR_x50 tuners in my setup in the meantime.

@George Mari - Could you send me the libmythtv.so library to sean _at_ whatafamily.org - I would like to try out the patch too. I also tried sending you an email that may not have gotten through.

comment:37 in reply to: ↑ 36 Changed 17 months ago by john_mythtv@…

Replying to Sean Donovan wiki user:mrsdonovan <sean@…>:

I have disabled the two PVR_x50 tuners in my setup in the meantime.

@George Mari - Could you send me the libmythtv.so library to sean _at_ whatafamily.org - I would like to try out the patch too. I also tried sending you an email that may not have gotten through.

Me too please, john_mythtv _at_ clonts.org

comment:38 Changed 17 months ago by Stuart Morgan <smorgan@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 3d13d795b2ae4a66f4bd3e5bdfd4168c66474282/mythtv:

Treat POLLHUP as EOF not an error, fixes IVTV (PVR-) recorders failing. Based on patch from ltskinol@… Fixes #10732

comment:39 Changed 17 months ago by Stuart Morgan <smorgan@…>

In 11ef5638504124a500c2fdbb47d2ca56f2c673af/mythtv:

Treat POLLHUP as EOF not an error, fixes IVTV (PVR-) recorders failing. Based on patch from ltskinol@… Fixes #10732
(cherry picked from commit 3d13d795b2ae4a66f4bd3e5bdfd4168c66474282)

comment:40 Changed 17 months ago by Stuart Morgan <smorgan@…>

In cd9f7eb68642f9052de40e68d544ccd40fc112a1/mythtv:

Treat POLLHUP as EOF not an error, fixes IVTV (PVR-) recorders failing. Based on patch from ltskinol@… Fixes #10732
(cherry picked from commit 3d13d795b2ae4a66f4bd3e5bdfd4168c66474282)

comment:41 Changed 17 months ago by stuartm

  • Milestone changed from unknown to 0.26.1

comment:42 Changed 17 months ago by ltskinol@…

My patch fixed two other bugs and made the code clearer. Why not apply the whole thing? I'm thinking that cherry-picking one line adds more risk than applying the whole patch, given that myself and a few others have shown that the whole patch is solid.

comment:43 Changed 17 months ago by Sean Donovan wiki user:: mrsdonovan <sean@…>

Downloaded the latest release for 0.25 and the PVR-x50 recordings are now working again - yah! Thank you Itskinol, et al.!

comment:44 Changed 17 months ago by stuartm

ltskinol - We prefer to keep unrelated changes separate in commits (and patches). The other changes were deemed less important but will still be reviewed and possibly applied later.

comment:45 Changed 17 months ago by jgelm@…

  • Resolution fixed deleted
  • Status changed from closed to new

How can this be marked closed?

I am having all of the above problems right now on a 12.04.1 mythbuntu system with Update Manager telling me "This computer is up to date. The package information was just updated.".

I installed the BE/FE system from scratch around 31 Oct 2012 and am sorry to tell you it is not fixed.

I am migrating from a U10.04 household to 12.04. I did the BE/FE first and now I am screwed. I chose 0.25 because it matched with 10.04.

Are these problems fixed in ANY version at all? Or do I need to roll back to 0.24 on the BE/FE?

The WAF is very low right now.

comment:46 Changed 17 months ago by danielk

  • Resolution set to Fixed
  • Status changed from new to closed

jgelm, this is not the mythbuntu bug tracker. We fix the issue in our source code and then the MythBuntu? project picks up the changes a few days later. As soon as it is fixed in our source code the appropriate thing to do is to close our ticket for the issue.

comment:47 Changed 9 months ago by durandal@…

Hi. Sorry for the question on this bug tracker but I'm a bit new to this and an answer would help me and perhaps others too.

I seem to have the problem described above.
How can I tell which version this patch is applied to? I see a milestone and a version in this page's header.

My backend version is
MythTV Version : v0.25.2-15-g46cab93
MythTV Branch : fixes/0.25
Network Protocol : 72
Library API : 0.25.20120506-1
QT Version : 4.8.1

Is my version patched, and if not, what's the best course of action? (running Ubuntu 12.04LTS)

comment:48 Changed 9 months ago by dekarl

  • Ticket locked set

durandal, this is not the mythbuntu bug tracker.
Your version is from May 2012, the patch went into fixes/0.25 8 months ago in November 2012 [11ef56385].
Please enable tracking of fixes/0.25 in mythbuntu-control-centre (or even better fixes/0.26, if you like you can also test the upcoming 0.27)
See http://www.mythbuntu.org/repos

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.