PDA

View Full Version : [8.04] Choppy 16:9 LiveTV on Diskless Frontend



Verzweifler
October 15th, 2008, 08:15 PM
When watching LiveTV on my Diskless Frontend everything is fine for programs in aspect ration 4:3. Same with any recordings regardless what aspect ration...

But 16:9 LiveTV that makes use of my full wide screen TV (1280x720) starts fine but turns choppy after about 30sec (pixel errors, sound crackling...). However, simply rewinding by ten seconds completely resolves the choppiness, so it obviously cannot be an issue related to my nVidia graphics card (which I therefore exclude from the set of "usual suspects").

For "TV Playback" I selected the "CPU+" default settings; switching to "normal" or "slim" significantly reduces display quality to an inacceptable level; switching to "CPU++" shortens the period of the program getting choppy to less than 10sec. Again, rewinding helps.

Although having on hand a work-around, I just want to know the reason for the choppy display. If it's just a misconfiguration, I want to get rid off it.

I somehow suspect network problems. Remember, I use a Diskless Client that not only has to handle streaming from the server but also needs to handle the fact that its operating system also is remote, so the Gigabit network really has some traffic to cope with (especially when showing 16:9 contents).

However, I just do not see, why LiveTV (in almost live mode) is so much different to a -let's say "more delayed"- recording, since the traffic involved to my understanding should be pretty much the same.

Or is it maybe because the server has issues in saving contents to its filesystem while already streaming the same contents in parallel? That would be an explanation why standard recordings just work fine (and also LiveTV being "forced" to be not really live by rewinding a bit)

Questions I would like to ask you for answers. How can I trace down the issue? Any hints are appreciated.

As pointed out before, the Frontend might be busy on networking but "top" does not reveal extreme CPU workload. Same for the server. Both are interacting using Gigabit LAN. I am clueless on where to look first.

newlinux
October 15th, 2008, 08:27 PM
Are your 16:9 recordings HD mpeg-2 streams? What happens if you rewind 10 seconds and then go back to "live?" what's in your frontend logs when this happens?

With a gigabit network, it seems network speed shouldn't be the problem. Maybe disk speed? What filesystem are you using and what are your disk specs? It seems a little strange that playback profile setting affect how long it takes to stutter. Maybe play around with creating a custom profile.

I'm grasping at straws but these are things I would look at.

ian dobson
October 15th, 2008, 08:29 PM
Hi,

Sounds like a buffering underflow.

Do you see aything in the frontend log file?
What happens when you pause the choppy video then continue it?
Are you streaming from mythtv-backend or from the file system?

There is an option in myth-setup to increase the buffer for HD files, maybe you could play with this.

Regards
Ian Dobson

Octagonal
October 15th, 2008, 08:55 PM
Yeah I agree about the buffereing being the issue.
When I watch HD streams through mplayer I have to use the cache option below to avoid any stuttering.
mplayer dvb://HD5 -cache 8192

Also, I know with mplayer changing the video output renderer from X11 to gl or gl2 seems to take less cpu time.

anonymousdog
October 15th, 2008, 10:53 PM
With nVidia graphics make sure you use the restricted drivers. I also find that CPU-- profile yields good results with very low CPU utilization (in use with nVidia graphics). That's how I have my diskless clients setup, but I don't stream any HD.

SiHa
October 16th, 2008, 09:51 AM
If rewinding 10s cures the problem, maybe it's the HDD at fault? Do you have DMA enabled on your Backend HDD?

Remember Live TV is not actually live, it's buffered on the HDD. The 10s delay gives the drive more time to cope

I'm afraid I can't remember exactly how to check your DMA settings, but search for posts containing 'hdparm'

newlinux
October 16th, 2008, 03:33 PM
DMA status:


sudo hdparm -I <hard disk device>


for read speeds


sudo hdparm -tT <hard disk device>

Verzweifler
October 16th, 2008, 08:48 PM
Thanks for your replies, folks.

I verified that the drive I defined for storing LiveTV (storage group LiveTV) is really slow.

hdparm -t /dev/sd? resulted in

/dev/sda:
Timing buffered disk reads: 206 MB in 3.01 seconds = 68.42 MB/sec
/dev/sdb:
Timing buffered disk reads: 172 MB in 3.01 seconds = 57.05 MB/sec
/dev/sdc:
Timing buffered disk reads: 84 MB in 3.00 seconds = 27.95 MB/sec

So 28 MB/sec for /dev/sdc is really a show-stopper.

Checking the DMA-status revealed a surprise:

hdparm -I /dev/sdc | grep dma
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5

So the drive is runing at udma2 instead of udma5 as the others do...
Nice, so I tried to use hdparm to tweak my /dev/sdc, but hey, it keeps crapping on me with "inappropriate ioctl" messages.
What worked fine with the very same drive under Knoppmyth (where it was a /dev/hdc) does no longer work with Ubuntu turning the drive to /dev/sdc...

newlinux
October 16th, 2008, 10:59 PM
I think you can think libata for not being able to us hdparm to change DMA mode on IDE drives (I'm assuming this is an IDE drive - if SATA DMA mode is irrelevant)

http://linux-ata.org/faq.html#old_ioctls

Verzweifler
October 17th, 2008, 07:34 AM
I switched the directory for LiveTV storage to my /dev/sda, which is faster... Need to verify whether this really fixes it.

Since there are other issues to fix (see my thread on "Offset>181" errors), I'll stick to the work-around of rewinding 10sec.
Maybe those other issues are actually causing the choppiness. Who knows...?