News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - laz

#1
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!

:)
#2
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
#3
I'd mentioned this in the thread about skipping and it may or may not be connected.

Pressing pause during playback of a recording always seems to take about 2 s to actually stop playback. About half of the time, the video freezes instantly but the audio carries on for a couple of seconds before stopping.

If I then unpause, both video and audio start but the video runs speeded up for a second or so, presumably to catch up with the audio that stopped about 2 s in front when it paused. I thought it was doing this every time but not when I've looked a bit more closely.

Before an earlier update from git, I was seeing things like:
23:18:01.831696 [debug]  2015 Player - Switch state from 1 to 2
23:18:01.833666 [debug]  2015 Video - enter pause
{snip}
23:18:04.007473 [debug]  2015 Video - CommandFinished waited too long 31dc40 0 2
23:18:04.008880 [debug]  2015 Audio -  pause aud_rend idle ChangeComponentState
23:18:04.010742 [notice] 2015 Video - eventHandler 31dc40 0 0 2 0
23:18:04.012784 [debug]  2015 Player - UNLOCKING
23:18:04.013961 [debug]  2015 Audio - OMX_EmptyThisBuffer 5 failed 80001018 2

About a 3 s gap after entering pause before the CommandFinished timeout from the video and also an error from OMX_EmptyThisBuffer from the audio.

Trying this again now (after the git update today to remove some deadlocks) I see the same behaviour but I can't see the same errors in the debug output!

VVideoRec::drawBarClocks seems to be called about 18 times on pausing: is that correct? It just seems to be redrawing the same thing.

Laz
#4
I'm not sure whether this is a known bug or not. If I watch a recording and I skip forward several times either 10 s, 1 min, or to a cut mark, after about 3 or 4 skips the recording progress bar loses the yellow progress bar and the length and position numbers disappear.

Usually, I can recover the numbers and progress bar by going back to the main menu and then resuming the recording.

At other times, skipping leaves me with a black screen with no audio and all input is ignored. At this point, I have to use "kill -KILL" to kill vompclient. Using just "kill" gives messages in the debug output that it has received the kill message and is trying to shutdown but it fails to do so.

This is with latest git. I'm reading my way through the code but have yet to get enough of a grasp to know exactly where to look for this yet!

Skipping has always seemed to be a problem with all output plugins I've tried with vdr!

:)

Laz
#5
Sorry if this is a known problem but I'm only just getting to speed with this!

:)

After an evening's testing, SD recordings and live TV all work well for me. HD recordings and live TV give me video but no audio. The log shows lots of:


22:48:12.264200 [debug]  3427 Audio - We can not decompress 323 save for later 1 42f03024 0
22:48:12.277927 [debug]  3427 Audio - We can not decompress 322 save for later 1 42f03024 0
22:48:12.291955 [debug]  3427 Audio - We can not decompress 323 save for later 1 42f03182 15e
22:48:12.322358 [debug]  3427 Audio - We can not decompress 315 save for later 1 42f03024 0

and the occasional
[mp3 @ 0x1da8f00] incomplete frame
or
[mp3 @ 0x1da8f00] Header missing

This is all with DVT-T in the UK (Freeview). From my experiences with softdevice and xineliboutput, I seem to remember that the audio of these channels is in a fairly obscure format (AAC in LATM) and I think it needed a fairly recent ffmpeg from git to decode it properly. It used to need a fairly recent git checkout to decode it properly: is libavcodec + libavformat in raspian up-to-date enough to decode this audio?

Or maybe I'm missing something somewhere?!

Laz
#6
VOMP for Raspberry Pi / Alternative remotes to CEC
October 23, 2012, 22:49:46
I've been using vomp with a couple of Media MVPs on and off for a few years now (usually when my main xineliboutput client is borked!). When I happened upon this port for the Raspberry pi, I finally had a reason to buy one! ;)

I've only really started testing it as a vomp client in the last day or so but I've been really impressed so far and can see it taking over from my xineliboutput client that seems to need restarting more and more every day!

I finally have CEC working on the third HDMI cable I'd tried but I'm seriously missing a few buttons on my Sony Bravia remote, including the ability to skip a minute, etc.

I have a wireless keyboard attached which gives me more buttons but is not a very elegant solution!

Is there a USB remote that anyone can recommend for using with vomp? I've been using one of the grey Hauppauge remotes both with my Media MVPs and also with LIRC on my other vdr boxes over the years. If I could continue to use one of those, that'd be ideal but I very much doubt that's possible!

Laz