[mythtv-users] 0.25 LiveTV unstable

[Tom Bongiorno]

On Thu, Jun 7, 2012 at 2:32 PM, <tom.oli at gmx.de> wrote:

> Hello,
>
> I love MythTV and I've got for a couple of years a 0.21 system running, SD
> only.
>
> Now I try to setup a 0.25 system including HD channels. I fail to get a
> stable, enduring LiveTV.
>
> System: BE/FE on separate machines, BE lives as kvm guest
>
> BE-Host: Nehalem QuadCore, 24 GB RAM, Raid1 for guests, Raid5 for data, 2
> Dual DVB-S2 card (Digital Devices Cine S2 V6).
> BE: 1 core, 2 GB RAM, Raids passed as virtio, raid5 (for records) with
> XFS, DVB-card passed-through as PCI, MythBuntu 12.04
> FE: http://www.asus.de/Barebone_PC/S_Series_7L/S1AT5NM10E/#overview,
> MythBuntu 12.04, VDPAU activated
>
> I have 2 problems:
> 1. LiveTV runs some minutes up to an hour, then it stops with: "Video
> Frame Buffering Failed Too Many Times"
> 2. Switching from one HD-channel to another (LiveTV) leads to a mixed
> display of the old and the new channel (shows some milliseconds of old
> channel, then of the new, then of old ...).
>
> Let's start with problem 1. A typical BE log starts then with:
>
> mythbuntu mythbackend[]: I ProcessRequest ringbuffer.cpp:1086
> (WaitForAvail)
> RingBuf(/home/media/video/mythtv/records/1101_20120531192004.mpg): Waited
> 0.2 seconds for data #012#011#011#011to become available... 0 < 393216
>
> Over the time the waiting grows to a couple of seconds.
>
> Later then:
>
> mythbuntu mythbackend[]: W TVRecEvent ThreadedFileWriter.cpp:301 (Flush)
> TFW(/home/media/video/mythtv/records/1101_20120530233000.mpg:36)
> : Taking a long time to flush.. buffer size 390476
>
> And finally
>
> May 31 01:14:25 mythbuntu mythbackend[]: W TVRecEvent dvbchannel.cpp:381
> (CheckOptions) DVBChan(2:/dev/dvb/adapter0/frontend0): Selected fec_inner
> parameter unsupported by this driver.
> May 31 01:14:25 mythbuntu mythbackend[]: N CoreContext autoexpire.cpp:263
> (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 7.0 GB
> w/freq: 14 min
> May 31 01:14:25 mythbuntu mythbackend[]: E TVRecEvent dvbchannel.cpp:1103
> (GetUncorrectedBlockCount) DVBChan(2:/dev/dvb/adapter0/frontend0): Getting
> Frontend uncorrected block count failed.#012#011#011#011eno: Operation not
> supported (95)
> May 31 01:14:25 mythbuntu mythbackend[]: W TVRecEvent
> dvbsignalmonitor.cpp:91 (DVBSignalMonitor)
> DVBSM(/dev/dvb/adapter0/frontend0): Cannot count Uncorrected
> Blocks#012#011#011#011eno: Operation not supported (95)
> May 31 01:14:25 mythbuntu mythbackend[]: I TVRecEvent tv_rec.cpp:1014
> (HandleStateChange) TVRec(2): Changing from WatchingLiveTV to None
>
> CPU load of BE and FE is about 10% during LiveTV.
> My first suspicion was the DVB-card driver. I've tested both, the 3.2
> kernel drivers and the drivers from http://git.linuxtv.org/media_build.git
> .
> Then I focused to the guest ressources. Before I passed the the disks as
> virtio I'd used the qemu emulation. Virtio made an hdparm -tT 10 times
> faster. But the problems remain.
>
> Any idea, what else I can try?
>
> Is a virtualized 0.25 a problem? Does it need more ressources? My 0.21
> runs stable as virtualized XEN-guest with a 10th of ressources as the 0.25
> system has.
>
>
> Thomas
> --
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
> Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

Unfortunately, this is a problem that has existed for several revs of
MythTV.  I am not sure when it started, but I believe it was there is .22.
 Don't quote me on that one.  It has nothing to do with the backend or
frontend specs.  There seems to be some deadlock during program boundaries,
where the new ringbuffer never gets handed off correctly to the frontend.
 Hopefully, this gets escalated and addressed in .26 or .25-fixes.  If I
had time, I would look into the code as this is a critical function for me
as well.

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120607/cc98af9f/attachment-0001.html>