Messages

The makefile I checked out from git yesterday tries to build the MVP client instead of the raspberry pi client by default. Lots of build errors until I spotted that one! I assume this happened during the merge.

N.B., the default branch for vompserver is not yet 0.4.0rc so you need to tell git to grab the correct vompserver version if you upgrade vompclient.

Updated from git and I've had a good go at breaking it. I've not managed to yet! Hopefully that's sorted it.

As I said, not always reproducible, so we'll see with time. I've unlimited core size now so (hopefully!) I can get a bit more info if it happens again...

If I skip forwards by a minute (multiple times needed?) and then change the volume immediately, vompclient crashes. This doesn't happen every time but it happens to me every few days. vompclient exits (somehow) rather than hanging somewhere. I _think_ it happens if the progress bar is still visible when I change the volume (I can't reproduce it now to check!).

I've been trying to track it down with either debug output or through gdb but cannot reproduce it under these conditions, although I did get an "invalid free" message at one point.

N.B., this is with a generic mce remote and with volume controlled by vompclient rather than by the TV. (I had hoped this remote would work well but lags like mad, whereas the TV remote using CEC reacts instantly to skipping, etc.! I'm not yet sure whether this is just a crap remote or the mceusb module lagging. Probably both!)

I suspect this could be a race condition somewhere that only causes the crash without the extra lag of debug output or gdb. It could be the OSD handling or perhaps changing the volume with an empty audio buffer?

I've also noticed that there is a 2 s delay between pressing mute (i.e. vompclient mute rather than TV mute) and the audio stopping or restarting.

This is with current git source.

Otherwise, all working well: this has been my main vdr frontend for a few months now. The only thing I really miss is the ability to mark and cut recordings but you can't have everything!

I had to reduce the TCP Receive Window size to (I think...) 16384 or I had lots of stuttering with HD streams.

I'd not forced a test of this and not needed the facility until today!

Works a treat!

Laz

Hmmm...a quick test of a new build and it still seems to do the audio drop-out (at least for me).

I wouldn't worry too much about this one: it's only a slight cosmetic thing! I'll try to do a bit more in-depth testing and debugging later on.

Bizarrely, I don't think it does it every time but that could just be it happening coincidentally with a quiet part of the soundtrack!

Laz

No this sounds, as if one buffer is lost, I maybe add later some code, that may prevent this. (2s is also the period of buffered audio in omx).

Marten

It isn't that noticeable, really. I'm estimating the audio drop-outs to be about half a second or less (occurring about 2 s after unpausing). Having said that, it's less intrusive than a glitch caused by an error in the DVB stream!



Cheers,

Laz

Typical! I spend ages working out what was causing the delay and it gets fixed by a totally different method!



Still, it's nice to know your way around a bit of code (and I'm not convinced I could have fixed what I was looking at!).

A quick test and it seems to be working perfectly, i.e. pausing and unpausing as expected.

Keep up the good work!

Cheers,

Laz

EDIT: Sometimes there is a very brief loss of audio 2 s after playback is resumed. Is this be the timeout in VideoOMX::CommandFinished again? I've not looked in the debug output yet...

I don't know whether this is a known bug (or whether I'm just lucking in having this!) but if the connection to vdr is lost, vompclient shows the "Connection Lost" message but then becomes unresponsive. I have to use "kill -KILL" to kill it and then restart it.

(I've not yet looked into what is meant to happen, i.e. whether vompclient is meant to exit and then restart from a script or whether basically restarts within vompclient.)

Laz

I've attached a couple of logs that I've just saved to (hopefully) help track down the 2 s delay I see when pausing. This is with latest git.

Descriptions of file vomp_pause.log:
I started up vompclient, played a recording from the beginning. Left it to play for a minute or two.

I pressed pause: both video and audio carried on for ca. 2 s then they both stop and the progress bar appears showing a time of 0:00:04 (the time when the initial OSD timed out).

I pressed play and the time flashed something briefly before jumping to 0:01:37, audio starts normally and the video played rapidly for ca. 1 s (I think: see below). Then I exited vompclient.


Descriptions of file vomp_OK_pause.log:
The same as above but I pressed OK at 0:01:10 and then waited for a minute or so before pressing pause. This time after the 2 s delay, the progress bar showed 0:01:14 (the time when I pressed OK + 4 s OSD timeout).

I pressed play and the time briefly flashed 0:01:14 (I think) and then changed to 0:02:26.


Sometimes the video stops instantly and the audio carries on, whereas other times they both stop together after the 2 s delay. Whichever happens, after unpausing, the video is initially rapid, as it tries to resync. I think the rapid-video sequence after unpausing is longer when the video stops before the audio. (Not easy to test!)

My current thoughts are that the current position is unobtainable on pausing and after a timeout, the previously stored value is used. I may have a go at disable showing the progress bar on pausing to see if that is where the problem lies.

Laz

Excellent: just as I thought! I 'll save the 512 MB one for something that needs it!

Laz

I'd downloaded the updated firmware by hand from git to get 512 MB on my other Pi. Vompclient is currently running on a 256 MB Pi. Would there be any advantage of using the 512 MB Pi? I guess it's been designed to be fairly minimalist for when the MediaMVP was the only client.

Laz

Thanks for the warning. I did a dist-upgrade on Friday and it took me a while to work out that I no longer had any video because it had reset the memory split back to 192/64 MB! I've not tried anything HD since then, though. 

A quick test and it played back an HD recording fine (at least for a few seconds). Live TV on an HD channel didn't work but I suspect that's because my DVB-T2 device has fallen off the USB bus again! (I can try that again later once my vdr box has stopped recording so I can reboot it.)

Laz

Your recent git update (Fix invalid time) does seem at first sight to have fixed the problem I had with skipping. I've only had a quick test so far, skipping minute-wise (or 10-s wise) back and forth about half an hour into a film and it seems pretty resilient. Even repeatedly pressing skip as fast as I could didn't cause it to hang. This recording is one that always caused a hang after a 4-5 skips before this.



I'll stop being careful with how rapidly I skip and test some more...

Laz

The chunks of log I posted were coped from the other thread on the skipping problems (about the 5th post or so), i.e. from before the latest changes in git.

Since then, I think I've seen the "waited too long" messages but I've only outputted debug logs to a console rather than to a file so far (I'm trying to keep a small child out of trouble at the same time!).

However, a few more observations that may help until I can save some debug output this evening. If I play back a recording and skip at some point, if I pause several minutes later, I get the delay as described and when the progress bar and times are eventually shown, they show the position from the previous skip rather than the correct current position.

It looks like it fails to retrieve the real current position when going into pause and uses the previous value from the skip. If I press OK (during normal playback), the correct position is shown immediately.

When I unpause, the progress bar and time jump ahead instantly to the correct position.

So is the timeout when it is trying to get the current position when going into pause? It seems odd that it works straight away at other times!

It definitely feels like a very timing-dependent problem. I'm running this over an ssh session so that the debug output also streams across the network, rather than running it locally on the console, and so that may also affect the timing! (Both vdr server and raspberry pi are plugged into the same 100 MBit switch so it should be fairly quick.)

The joys of multi-threading...

Laz