Recordings fail after upgrade to .25

[daveshome@…]

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

[danielk]

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

[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.

[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

[SBMythTV@…]

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

[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)

[Kenni Lund [kenni a kelu dot dk]]

Requested logs provided by two users.

[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

[Michael Harnden <mike@…>]

Backend and Kernel logs of latest failure

[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)

[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.

[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).

[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.

[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

[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

[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

[danielk]

Was the Linux kernel also upgraded?

[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.

[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.

[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.

[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.

[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" ?

[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).

[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

[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

[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.

[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

[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.

[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.

[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.

[Kenni Lund [kenni a kelu dot dk]]

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

[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.

[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.

[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.

[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.

[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

[Stuart Morgan <smorgan@…>]

In 3d13d795b2ae4a66f4bd3e5bdfd4168c66474282/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Stuart Morgan <smorgan@…>]

In 11ef5638504124a500c2fdbb47d2ca56f2c673af/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Stuart Morgan <smorgan@…>]

In cd9f7eb68642f9052de40e68d544ccd40fc112a1/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[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.

[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.!

[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.

[jgelm@…]

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.

[danielk]

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.

[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)

[Karl Egly]

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