*Don't PM me directly for support, open a new thread
*Looking for a MythTV quick start guide?
I never had this happen until the latest Ubuntu Precise update (kernel is 3.2.0-22-generic #35-Ubuntu SMP Tue Apr 3) and now it happens every time.
No problems on my 11.10 machine. Actually even if I use an older kernel, it still happens with Precise. @%&@%&@%&
Anyone else seeing this?
I've recently upgraded from MythTV 0.24 to 0.25-2 and I now get intermittent recording failures which prevent all future recordings until reboot. I've deleted all tuners and re-added them after the upgrade with no change. Several dozen MultiRec recordings will happen just fine, and then a recording gets "stuck" on a tuner and all future recordings on any tuner seem to not get dispatched. Several hours after the recording should have ended the "stuck" recording is still shown as green in Previous Recordings list along with status O, implying it is still recording, but no file is created; missed recordings don't show in the Previous Recordings list at all. After reboot the missed recordings show as red with status M in the Previous Recordings list. So far all failures have occurred only on HD-5500 (2 different systems) and only when MultiRec>=2. HDHomeRun with default MultiRec=2 so far has not shown the problem. Also HD-5500 with MultiRec=1 (no MuntiRec) has not shown the problem. I can't see anything in the mythbackend.log to give any insite into the failure.
First from 11.10/0.24 to 11.10/0.25, which worked fine, then after a week or two updated to 12.04/0.25.
Since the 12.04 update I get maybe one in ten recordings work, the other 9 out of ten are zero byte.
I have two tuners, a Sony PlayTV and an Asus 3100 Mini, both which use the dib0700 chipset, and get the same results when using either. I've deleted them and re-added them, tried increasing the tuning timeout and the tuning delay, all without any joy.
I've got clonezilla backups of both versions and have switched back and forth between the two, and its fully repeatable.
I just tried a mainline kernel, 3.3.0-994.201203080434, and the problem still occurs with that.
Planning on trying 12.10 and 0.26, separately and together.
Edit: 0.26 hasn't fixed it (it doesn't look like a MythTV problem)
Edit: running with the previous precise kernel (linux-image-3.2.0-31-generic-pae ) seems to have fixed it. Either the current version is broken, or something went wrong during my 11.10->12.04 upgrade. I guess I'll find out when 3.2.0-33 comes along.
Last edited by The Toastcutter; November 7th, 2012 at 11:14 AM. Reason: Added problem resolution
Zero-byte recordings have been a particular problem for me since upgrading my system to Mythbuntu 12.04 + MythTV 0.25 (currently kernel 3.2.0-33), and do not appear to have been helped much by moving forward to MythTV 0.26.
My tuner is a USB HVR-950Q. It is attached to a terrestrial ATSC antenna with good reception, which is the only signal/input source.
I also experience "Error opening jump program file buffer" when changing channels in LiveTV mode and frequent "Partial Lock" behaviour when tuning the channels. This was new to me with 12.04+0.25. Previously I was running 11.10 and MythTV 0.24 and never saw this; it happens all the time now. I have not seen any discussion relating these behaviours... but I find it odd that they should manifest at the same time. My gut tells me the Partial Lock on channel tuning bears some relation to the failed recordings.
The zero-byte recordings were intermittent (say once per week) with 11.10+0.24 but now they have become closer to once per day. The behaviour is inconsistent but, as noted elsewhere, the problem seems less likely to manifest itself after the system (or backend) is stopped and started. It is also inconsistent in that a 7-7:30pm recording may go successfully, but the 8-9pm recording fails. Also, if the 8-9pm recording fails, then the 9-10pm recording on the same night will usually fail.
I have a combined frontend/backend machine. It shuts down when idle and wakes itself for the next recording. The backend logs show nothing out of the ordinary when starting the recording, but thereafter you can see where the commflag process can't use the file. System status indicates the recording is in process for the whole time of the scheduled program
I have tried most, if not all, of the suggestions in this forum:
- Moved the USB tuner to a less warm area by way of an extension cable
- Deleted and re-added the capture card, channels, etc.
- Upgraded to 0.26 (2:0.26.0+fixes.20121114.... from Mythbuntu repository)
- Disabled EIT collection
- Changed tuner timeouts
It seems like the only way to improve the likelihood of sucess is to regularly stop and start the backend or reboot the whole machine.
My tuner problems seem to have been introduced with the 3.2.0-32 kernel, and are still happening with 3.2.0-33. I get near-perfect recording with 3.2.0-31.
Rocco64 - have you tried this with the 3.2.0-31 kernel?
I have not... I'll see if it's still installed.
Update: 3.2.0-31 reinstalled and set as the default today. Not enough scheduled recordings have passed to give a verdict; will follow-up in a couple of days.
Five days on and no failures in a dozen recordings; this qualifies as a success!