Page 1 of 1
Master 0.28 Increase in Frequency of 0 Byte recordings
Posted: Fri Jan 09, 2015 3:05 pm
by jksj
Just to provide more info around the issue of 0 byte recordings on 0.28 Master being discussed in the development forum.
I record DVB from both Freesat (PCI) & Freeview in the UK (USB).
I have never experienced any failed recordings with the PCI based Freesat recorder.
The USB based Freeview recorder has been reporting occasional failures (approx 10% of recordings) since 27/10/04.
This is about once or twice a week so it is difficult to pin down a committ.
The two previous updates installed were.:-
v0.28-pre-2346-g1830246
v0.28-pre-2323-g1e6778e
I had put the problem down to bad weather causing reception issues until the topic was brought up in the development forum.
I have mitigated the issue by reducing the number of channels simltaneously received from 2 to 1 and reducing the number of muxes polled for EIT by 2. This seems to have sorted it. No doubt by just speeding things up a fraction.
N.B. the tuning timeout was 5 secs , increasing it to 7 has no effect apart from delaying the failure report.
LiveTV does not exhibit the issue you can do 20 consecutive channel changes, so it is not the tuner.
Quicktune is enabled for both livetv and recordings on this tuner. I cant remember why but its been like that way for two years. Currently running with mythbackend --setverbose channel but its not screwing up anymore
Re: Master 0.28 Increase in Frequency of 0 Byte recordings
Posted: Wed Jan 14, 2015 5:59 pm
by jksj
Some more info:- Looking at the last two lines - the tuner achieves lock but this is not recognised by the tuning signal check.
Once this state is entered all future tuning requests on that tuner fail identically.
Code: Select all
Jan 13 21:04:56 tv mythbackend: mythbackend[3060]: I EIT tv_rec.cpp:3175 (QueueEITChannelChange) TVRec[14]: QueueEITChannelChange(6) -- begin
Jan 13 21:04:56 tv mythbackend: mythbackend[3060]: I EIT tv_rec.cpp:3193 (QueueEITChannelChange) TVRec[14]: QueueEITChannelChange(6) -- end --> 1
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbchannel.cpp:180 (Open) DVBChan[14](/dev/dvb/adapter102/frontend0): Opening DVB channel
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dtvchannel.cpp:181 (SetChannelByString) DTVChan[14](/dev/dvb/adapter102/frontend0): SetChannelByString(6):
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbchannel.cpp:466 (CheckOptions) DVBChan[14](/dev/dvb/adapter102/frontend0): 738000000 auto 0 auto auto 8 a 1/32 n v fec: auto msys: UNDEFINED rolloff: 0.35
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbchannel.cpp:706 (Tune) DVBChan[14](/dev/dvb/adapter102/frontend0): #012Old Params: 738000000 auto 0 auto auto 8 a 1/32 n v fec: auto msys: UNDEFINED rolloff: 0.35#012New Params: 738000000 auto 0 auto auto 8 a 1/32 n v fec: auto msys: UNDEFINED rolloff: 0.35
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbchannel.cpp:859 (Tune) DVBChan[14](/dev/dvb/adapter102/frontend0): Tune(): Frequency tuning successful.
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dtvchannel.cpp:348 (SetChannelByString) DTVChan[14](/dev/dvb/adapter102/frontend0): SetChannelByString(6): success
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbchannel.cpp:180 (Open) DVBChan[14](/dev/dvb/adapter102/frontend0): Opening DVB channel
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbsignalmonitor.cpp:91 (DVBSignalMonitor) DVBSigMon[14](/dev/dvb/adapter102/frontend0): Can measure Signal Strength
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbsignalmonitor.cpp:93 (DVBSignalMonitor) DVBSigMon[14](/dev/dvb/adapter102/frontend0): Can measure S/N
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbsignalmonitor.cpp:95 (DVBSignalMonitor) DVBSigMon[14](/dev/dvb/adapter102/frontend0): Can measure Bit Error Rate
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbsignalmonitor.cpp:97 (DVBSignalMonitor) DVBSigMon[14](/dev/dvb/adapter102/frontend0): Can count Uncorrected Blocks
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dvbsignalmonitor.cpp:104 (DVBSignalMonitor) DVBSigMon[14](/dev/dvb/adapter102/frontend0): DVBSignalMonitor::ctor initial flags Seen() Match() Wait(Sig,SNR,BER,UB,)
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I TVRecEvent recorders/dtvsignalmonitor.cpp:238 (SetDVBService) DTVSigMon[14](/dev/dvb/adapter102/frontend0)::SetDVBService(transport_id: 16520, network_id: 9018, service_id: 17920):
Jan 13 21:04:57 tv mythbackend: mythbackend[3060]: I SignalMonitor recorders/dvbsignalmonitor.cpp:301 (UpdateValues) DVBSigMon[14](/dev/dvb/adapter102/frontend0): UpdateValues -- Signal Locked
Jan 13 21:05:04 tv mythbackend: mythbackend[3060]: W TVRecEvent tv_rec.cpp:4047 (TuningSignalCheck) TVRec[14]: TuningSignalCheck: taking more than 7000 ms to get a lock. marking this recording as 'Failing'.
Any ideas?
Re: Master 0.28 Increase in Frequency of 0 Byte recordings
Posted: Sat Mar 21, 2015 9:32 am
by jksj
This issue has not re-occurred since updating to Ubuntu 14.04.2 even when sticking to kernel 3:13, suspect it was a USB3 issue fixed by a bug fix to xhci.
Re: Master 0.28 Increase in Frequency of 0 Byte recordings
Posted: Sun Apr 12, 2015 8:09 pm
by StrvnMrvn
That's rather odd. My troubles with VBR transport streams from a DCH-3200/firewire (US/Comcast) began after moving from 0.27-fixes to 0.28-pre-2744 (using mythbuntu PPAs). Detailed in this
this post.
I was fairly certain it was due to inadvertently dist-upgrading mythbuntu into the 3.16 kernel but maybe it is one of the commits in the 0.28 branch. We'll find out after I rebuild it with 14.04.1 and hold the kernel to 3.13
Re: Master 0.28 Increase in Frequency of 0 Byte recordings
Posted: Tue Apr 14, 2015 8:04 am
by jksj
The major improvement with XHCI (USB) reliability in Ubunty Trusty 14.04.2 (both the 3.13 & 3.16 kernels) relates I think specifically to Intel Haswell processors and NUCs.
The issue where you cannot run two USB tuners of the same type still remains.
Re: Master 0.28 Increase in Frequency of 0 Byte recordings
Posted: Tue May 05, 2015 10:40 am
by plainfaceboy
I started getting some 0-byte recordings with 0.28 (and 14.04.2). At first a re-boot fixed the issue, but this time I lost all my channels. (PCI card - HVR4000).
I also lost my DVD drive. I tried various things eg re-added card and rescanned etc but eventually went for a fresh install.
I've resinstalled 14.04.2 from ISO - my DVD drive is back. I'm wondering if I should be installing this with mythtv 0.28?
eg When installing the mesa-vdpau-drivers which I thought I need for mythtv, I now get unmet dependencies (re. libcheese and libclutter).
Am I going to have problems ? Do I still need these drivers?
I also got the same issues with things I previosuly had to install to get the proprietary AMD drivers working.
Does anyone have any advice on mythtv 0.28 with Ubuntu 14.04.2 - if there are any known issues, and/or if I should stick with older versions?
Thanks.
Re: Master 0.28 Increase in Frequency of 0 Byte recordings
Posted: Wed May 06, 2015 9:00 am
by jksj
mythtv 0.28 with Ubuntu 14.04.2 is currently reliable but your better off sticking with 0.27 fixes, if you are having other hardware issues. At least you then know its not myth that is causing them.
If you installed 14.04.2 from iso you will be running the 3.16 kernel, which I had problems with.
Installing 14.04.1 and updating it to 14.04.02 retains the 3.13 kernel currently at 3.13.0-52.
.