LiveTV takes a while to start, and video jerks forwards

[mythtv@…]

Latest version of MythTV:

Library API version: 0.19.20060121-2 Source code version: Unknown Options compiled in:

linux release using_v4l using_oss using_alsa using_arts using_ivtv using_dbox2 using_lirc using_joystick_menu using_dvb using_dvb_eit using_x11 using_xv using_x

randr using_xvmc using_frontend using_backend

SVN version 8867

Problem has been around since around version 8400 and I mistakenly thought this problem was related to another ​ticket.

I'm using Debian Sarge with 2 x Nova-T DVB cards with latest SVN version of MythTV

When I start Live TV - it takes quite a while to start, showing a black screen for about 10 seconds, then pops up a bar on the bottom with something like:

Signal 0% | Sn/N 4.8dB | BE (0) | LAM: Lock

and a tiny purple square on the bottom right with hortizonal white lines in and after a few seconds, the video starts but the video jerks faster, like normal speed->faster ->normal speed->faster->normal speed and so on. I can only stop this if I adjust the time stretch to 0.9 and then back to 1. Then the problem goes away, and video plays normally, and I don't see this problem until I exit and re-enter Live TV or change tuners. I will be attaching the frontend and backend logs.

[mythtv@…]

Backend logs

[mythtv@…]

Frontend log

[mythtv@…]

Oops, forgot to put in my email address when posting this ticket, I am the poster. Just an FYI.

[danielk]

Can you test this again with SVN rev >= [8871].

[Merlin83b]

Seeing this too, will keep an eye on ticket

[mythtv@…]

No difference with 8872

[danielk]

biased, you are using streaming, right?

What kind of network are we talking about?

100-base-t, 1000-base-t, other?

Have you tried sharing the volume via NFS?

[mythtv@…]

Streaming - not 100% sure, I think I am, just using mainly default settings with nothing exotic. Yeah, am using ethernet - 100-base-t via a switch. It worked perfectly fine until a month or so ago. How do I watch Live TV via NFS?

[Merlin83b <daniel@…>]

This is happening for me with frontend and backend running on the same machine.

[mythtv@…]

Also happening for me, (UK Nova-T card), ... what governs the use of streaming?

[danielk]

(In [8880]) Fixes #1219.

Streaming requires additional buffering, so it will always be slower to start than using a local or shared directory store.

But this commit addresses an inefficiency introduced by changing the block sizing in [8841]. The FileTransfer? had a fixed maximum block size of 256000, but I changed the equivalent block size in RingBuffer? to 256 KiB (or 262144 bytes). FileTransfer? dealt with this by breaking it up into a 250 KiB and 6 KiB transfer. This didn't make enough of a difference to be noticable on my network (it increases the number of ethernet packets by less than 1%), but on a very marginal system it could make a difference.

I highly recommend using an NFS share or the equivalent for the video directory on HDTV remote frontends. We apply several optimizations for read size and buffering level when using a local RingBuffer? which we don't do when streaming. It requires a higher end backend to stream HD material than to shares store with the frontend (faster hard disk mostly); and then it still isn't as quick to start up.

[mythtv@…]

I'm not using HDTV - we Brits don't have HDTV just yet ;) Just bog standard PAL. But I will try >8841 tomorrow morning. Failing that, will try NFS. I'd be surprised if it's all to do with slow systems as am using 3 frontends - a P3 666, a XP1700+ and a PPC 1.25GHz, and the backend is a Nehemiah 1.2Ghz all connected via 100mbit ethernet. All the frontends shows the same symptoms, and I've used all 3 frontends for months and the backend for over a year without any problems until a month ago.

[mythtv@…]

Tried upgrading to 8891, problem still exists. Tried using MythTV via NFS, problem still exists. I don't use HDTV, and have used MythTV for over a year now without any problems between the Nehemiah 1.2GHz and the XP1700 worked perfectly fine without the long startup and jerks and now the long startup and jerks happened a month ago. Like I said, the jerks will go away if I adjust the time stretch from 1 to 0.9 and back to 1 which smacks me of a bug. If you don't believe that this is a bug, just close the ticket and I will never speak of the subject again and live with adjusting the time stretch every time I start Live TV.

[adrian.wilkins@…]

I ... also... see.. this ... problem ... and ... have ... been ... annoyed ... by ... it ... the video ... surges ... faster ... and ... slower ... a bit ... like ... this.

Recently seems to have abated. I've been associating it with the vastly increased backend CPU utilisation I've seen recently. Re-nicing my frontend to -15 helped a little, but I think using the Bob deinterlace may have cured it.

Another question ; could the original reporter try switching his deinterlace to Bob and tell us if that fixes it?

[Merlin83b]

I'm on bob deinterlace and have the problem with taking ages to start watching livetv, but haven't noticed the jerky forward thing.

I always have frontend at nice -20 and backend at -15.

[danielk]

Closing as [invalid].

There is nothing reproducable in this report, and the report also does not contain the revision that caused the problem.

[Mark Spieth]

attached is a patch to help the startup hiccup. those experiencing please test.

[mythtv@…]

*think* I patched it successfully, but the problem is still there :/

[mythtv@…]

Interesting - changing to bob deinterlacing stops the jerky forward problem from happening but text looks dodgy, and the whole screen flickers slightly - would rather use linear blend. Changing back to linear blend makes the problem happen again. With One Field deinterlacing, the problem seems worse. Using Kernel deinterlacing is as bad as One Field. Disabling deinterlacing doesn't make the problem goes away. So it seems that all deinterlacing methods apart from Bob and disabling deinterlacing has the problem but enabling Bob fixes the problem but it causes me to have headaches quite quickly! Hope this is of some help.

[Merlin83b]

I applied the patch to SVN 8904 but no luck - it still takes in excess of 20 seconds to start up LiveTV, and something like that to change channels.

[danielk]

Closing as [invalid].

There is nothing reproducable in this report, and the report also does not contain the revision that caused the problem.

Mark, open a seperate 0.20 enhancement ticket for the audio stuff.

Biased & co, you need find the revision where this problem started. Or, if you changed compilers (gcc 3.x to gcc 4.x say), try reverting the compiler. It is possible that some new optimizations in your compiler are hurting performace; I've done some benchmarking here and playback performance has improved in the last couple months.

[pekka.jaaskelainen@…]

I reopened this ticket because this is clearly a regression to me. I'm free almost the whole weekend for helping in debugging, in case there's someone who tries to fix this.

Here's my problem description from my reply to a list thread:

I experience this problem with revision 8905.

On a remote (over a WLAN connection) frontend machine that has 256MB RAM and a Duron 800MHz CPU, I get around 30 sec channel change times, and when I check the position bar after the channel is changed, I see that I have 30 sec of the program "to go". The video seems to "speed up" to catch the rest of the video for a while, thus jumping a bit due to the little processing power of the frontend machine.

On the machine that hosts the backend (P4 2.6GHz, 1GB), I get the same effect, only it's less drastic: the change time (and the prebuffer length after channel change) is around 15-20 secs.

The previous revision I used to run was 6946 and the delays was then around 5-10secs which is (almost) tolerable.

Anything I can do to help tracking this out?

If I have to binary search a revision in which this occured, it's going to take *a lots* of time, as the revision window is quite big and it takes 1-2hours to recompile MythTV with my machines. But if it's the only way, I'm ready to do it too, time permitting.

The problem seems to be that MythTV is overly cautious with prebuffering. The 30 sec buffer seems overkill to me.

[bjm]

...still not a message board. We have discussion mail lists.

[buzz@…]

to: pekka.jaaskelainen@…

danielk and bjm have both colsed this ticket because (among other things) you have failed to identify the "revision that caused the problem". This doesn't mean "some revision where the problem occurs", it means "the exact revision where the problem started to occur". Yes, this means, you may have to do a binary-search of 1000 or so revisions, but that's only worst-case about 10 compiles, or 20 hours. Less than one day. If you use your brain and actually look at the change-sets/commit logs , I'd say you can possibly halve-that. Have fun, reopen when you have a SPECIFIC revision where the problem started.

[anonymous]

This is still a problem on the official 0.19 release!

I'm using:

Ubuntu Breezy 2xDVB-T cards Athlon XP 2000+ 768Mb Ram 400Gb Free HD space

mythbackend is using about 45-50% cpu while watching TV