Topics

As I boot my MVP from a small NAS device I was searching for an option to connect to a particular server after startup but waking it up before with WOL. Additionally as my master power switches on a lot of devices, I wanted to boot the MVP into standby mode (i.e. not waking up my server each time I switch on power.
With the patches I include here, the vompclient accepts 2 new options:
-e ethaddr - if -s server-ip is also given, use this ethernet address to wake up the server
-o - start in standby mode
To use this you can edit /etc/rcS for the startup command of the vompclient to something like:
/vompclient -o -s 192.168.1.99 -e "00:30:84:25:e9:f8" &

Maybe someone would like to create a tool to also patch the dongle for different startup options...

Regards
Andreas

In the german vdr forum we had some reports about missing the last seconds when playing a VDR recording.
See http://www.vdr-portal.de/board/thread.php?postid=766497#post766497

As I understand the code, this is related to the buffers in the stream classes. The playerlivetv will stop it's thread (and this way dismiss) as soon as it has delivered the last packet to the demuxer. But afterwards there is still a lot of data in the buffers...

My solution in the playermedia is the following:
1. remember the last parsed PTS in the demuxer (i.e. the packet just delivered to the stream)
2. when the last chunk of data has been delivered to the demux I start a timer (max. 15s) and in parallel wait until video has seen the last delivered PTS.
3. if video has seen the last PTS I start another timer of 3s to have the last frames
4. if either the first or the second (short) timer fire I will stop

I guess the same solution could be used for the recordings player.

Regards
Andreas

Hi all,
after I had a couple of problems especially on high bandwith channels (ARD I)  - vomp locked or crashed, I had some code review and found there is no protection for the shared data structures in playerlivetv. But at the end there are 3 threads working on them - receiver,player,GUI. This can easily lead to data corruption. On the other hand the playing thread could block forever...
So I created some patch that solved the problems (based on cvs 2008/11/28).
Additionally I also rewrote the ts demuxer to avoid at least copying all the data twice - this seemed to increase the performance a bit (less artefacts).

I attach the patches here.

Andreas

Hi Chris,
when I was playing with timers newly I saw your comments in the timers.h.
I have the following proposal:
1. Leave the existing timer handling available
advantage: no need to change a lot of code
2. add new functions like follows:
setMessageTimerX(Boxx *listener, int id,....)
So this can only be called by Boxxes (at the end it should be restricted to views - but now there is no separate class any more...).
If a timer registered this way fires, a message will be send to the particular view.
So we can easily define a TIMER_EVENT message, having the client ref as parameter.
New code can easily use this extended interface, have the timer handling in processMessage and can avoid the postMessage calls.
Even porting of current code would be easy at many places because the real handling is most probably in processMessage anyway.

This approach would combine the advantages of the current solution (precise timers, also for non view elements) with the ease of your new proposal.

Regards
Andreas

Hi all,
because I work all the time a bit away from my vomp - accessing it via telnet and using netcat -u to simulate remote key-presses -  I now wrote a small (java) based simulator for the remote.
By taking a photo of it (hmm quality...) and having a key mapping file attached, you can now click with the mouse on the keys and it will send out appropriate UDP commands.
Currently for the old remote (that's what I have) - but it could be easily adapted to the new one - see included file USAGE.TXT.
For me it works (now it's easier to remember all the keys - and you got a feedback where they keys are located and if certain functions make sense).
Maybe it could help somebody else too.
Simply unpack attached file to an empty dir and run:
  java -jar usender.jar remote/oldremote.jpg vomp-ip
!! there was a typo in this command before (missed usender.jar)!!
Needs java 1.5.

regards
Andreas

To help finding problems when vomp is crashing or hanging, i wrote a small program, that allows to run vomp in debug mode for a long time, managing a set of logfiles with limited size and number.
Basically this works for the nfs mounted devenv version, for the real dongle version I would need to figure out a ramfs location to avoid heavy writing to the flash.
To build the tool, just create an directory below the vomp directory where you did run makedevenv (just in parallel to dongle, client,...).
Unpack the attached tar, call make.
You will get vdebugrot. Copy this to your nfs location and start vomp like this:
/vompclient -d 10 2>&1 | /vdebugrot /vomplog 2048 5 &
This will handle a set of 5 logfiles (/vomplog.01..05) each having at most 2048 lines and a markfile /vomplog.cur.
If a file gets filled, the next one is opened. Each restart will open the next file too.
This way you always will have a reasonable amount of the debug output available after a vomp crash - simply ls -tr and get the related logfiles.
To make this the permanent start command, replace the /vompclient line in /etc/rcS with the above command.

Regards
Andreas

Hi all (esp. Chris),
I like vomp a lot - great work!
I use it now heavily and found it lacks media player functionality (anyway works much better then mediamvp oder mvpmc...).
So I started to work on adding media player functionality.
Currently I got the picture display working (was prio 1 for me). So I would like to share this with you - and to start discussion about some further work.
I've prepared the patches against todays cvs for client and server. Should I post them here? (about 150k).
- aa - they include WOL too (I use this heavily)...
@Chris: What do you think - would you like to integrate this into the project? I saw there is heavy progress in CVS - so I got my last snap about 2 weeks ago and I needed some time to merge everything...
I would be happy to put the staff into CVS...
Maybe some short Ideas about further work:
My prio 1 would be the audio (mp3) player - but I saw that there is ongoing work in the player area - so difficult to manage this.
I attach at least my readme that contains some descriptions and an overview about the functionality.

Regards
Andreas