Messages

Hi,
after I uploaded now a version that is able to play videos (http://www.loggytronic.com/forum/index.php?topic=248.msg2053#msg2053, maybe someone would be interested in adding this.
The media player now internally has a hierarchical structure of media providers, so it should be fairly easy to add a streaming receiver locally at the client side.
It needs to implement MediaProvider - and would need some configuration (like a playlist).
Optionally you could try out the new server side plugin interface. If you would use e.g. mencoder (or some other simpler program like wget if the stream is well formatted) that is able to receive streams, you can add the wanted channels as files in a dedicated directory.
For example you could create a script to handle files of the extension "stream".
Those files will simply contain the URL to be streamed.
Eg: mystream.stream

Code Select Expand

http://192.168.2.7:31344


The command configured to handle the extension "stream" would inlcude

Code Select Expand

....
if [ $1 = play ] ; then
    wget -O - `cat "$2"`
fi

The disadvantage would again be that it goes through the server...
The client side would require some C++ hacking 

Regards
Andreas

Hi all,
I just uploaded some bugfixes and extensions for the version 2008/03/20.
Please be aware that there was an error in the documentation for the script interface.
For testing the availability the program is called with the parameter "check".
Files are here:http://www.wellenvogel.de/software/vomp/index.html#Update_080322

Regards
Andreas

Hello all,
I just finished a new version of the media player, being able to play videos.
Additionally you can insert server side script commands to convert media on the fly.
Please refer to http://www.wellenvogel.de/software/vomp/index.html#Update_20080320.
Any feedback is highly appreciated.

regards
Andreas

Hi Chris,
my feeling is that it would lead to a lot of serious problems in a couple of view (boxx-) implementation if the code dealing with display functions could be called from within multiple threads (i.e. a key press and a timer firing at the same time). This would require all this code to become thread safe.
Currently the pattern is quite simple:
everything that is triggered by handleCommand or processMessage is promised to be called only from one thread at the same time

The question is:
What are typical actions to be done within a timer call?
I guess very often it is e.g. updating a (child) view or myself with creating new strings, GUI objects (or even views).
This would have to be thread safe...

I personally would stick at the current pattern to just send a message to myself when a timer fires in boxxes.
For other objects (e.g. players) things are different - they have threads anyway and thread safety has been an issue just from the beginning - so it's typically not a real problem to have timer calls from within different threads.

So at least I would prefer a timercall (message or callback - no big diff from my pov) for boxxes synchronized with the global mutex - this would free me from dealing with thread safety in the rest of the boxxes code.

At the end introducing additional syncing in the boxstack would make operations a bit slower - but I don't think that this is really an issue.

Regards
Andreas

[both sides]

Hi Chris,

Andreas: I have had a quick look at the serialize stuff, but I think I will need to look at it some more later. It looks a lot like some of the latest networking code already in cvs for dynamically making packets, so we will have to work out which way to go with these things.

I had the following major intentions:
1. easy use
The use of some data holders on both sides (client+server) makes it quite simple and straightforward to implement new protocol features or extend existing ones. If we would go this way, I have some ideas about a small testing framework that will easily allow for testing those data holders separately (by writing the serialized data to files and reading it again - so we could even test version compatibility). You will get nearly completely free of any protocol issues that are typically hard to debug.
2. version compatibility
With the proposal you can easily get forward and backward compatibility by following some simple pattern (i.e. only add elements, always add at the end in serialize). This way you can run a server x.1 against a client x.5 and can easily handle it on both sides.
3. Not too many classes
By providing the SerializableList for simple messages you can create protocol messages on the fly without really writing the serialization/ deserialization (by the minor drawback of the dynamically created list).
I already saw that you did something in the protocol (so obviously the serialize buffers are similar) - but (as far as I understood) there is no version/length encoding of each element - that is the prerequisite for such compatibility stuff (at least if you would like to have forward comp. too...

I used the code now within the commands for the mediaplayer with the newest patches...

Regards
Andreas

To download patch-media-all-cvs080106.txt.gz, I see patch-server-all-cvs080106.txt.gz for download.

Should be OK now.
Sorry
Andreas

Hi Harry,
it's still on the list...
I had to decide whether to release the things I have or not -Holidays are gone now, so time gets limited again...
Prio 1 for me currently is Video.
The cfg file issue is one of the next..

Regards
Andreas

Hello all,
today I finished a new version of the mediaplayer (basing on current cvs).
The major new features are:

• audio and picture in parallel
• playing directories recursively
• exif orientation
• colourtuner
• better scaling
• completely internal rewriting (OK no feature...)

The complete set of patches can be found as usual at:
http://www.wellenvogel.de/software/vomp/index.html#Update20080106
Any feedback is highly welcome.

Regards
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

[old]

Hi Chris,
hmm - it's too simple - so coordinates depend on the size of the underlying label.
Anyway - it was 10 minutes to adapt the file for the old remote after enlarging the JLabel.
Now it seems old and new are working well.
I added a display for the send command - so you have an easy check for that.
I just created a new complete archive with the old+new remote inside.

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

Hello Chris & all,
what would you think of introducing some versioning and compatibility handling at the interface?
I started now some work that I needed for the mediaplayer - basically there are some simple patterns that would allow for easy compatibility handling:
1. have some data holders (classes with no reference to anything except defines.h)  that are used on both sides
2. make them serializable with some version handling included (I'm just done with the necessary classes I use for the mediaplayer)
3. being a bit carefully when adding new attributes to the classes (just ADDING, not changing semantics)
With this simple approach we could easily maintain compatibility at the interface that would allow us to be more flexible. I guess a lot of people would like it to be able to run e.g. the newest dongle against an older server plugin (OK some functions will not be available - but it works).
At the end we could also add some protocol version that could be send from the server to the client (and vice versa)...
Just to illustrate my ideas I add here some files that I used now to have serializable data holders with versioning for the media player (they will become part of the next media player patches).
serialize.*
  - base classes for ser/deser (just adding 6 bytes overhead for a class - 2Bytes version, 4bytes length)
  - SerializableList - a simple container class to construct VDR-commands (see vdrcommand.h) without explicitly implementing serialize/deserialize
media.*
- examples how I use this for the media player

At the end the above patterns would also ease the testing of new protocol features (I'm just thinking of creating a small testing framework to test serialize/deserialize + compatibility) - this way we can implement and test the data holders independent of everything else - and there is no need to "frickle" with protocol details.

What do you think of such an approach?

Regards
Andreas

Hello all,
a new version of the media player extensions is available at
http://www.wellenvogel.de/software/vomp/index.html#Update20071202.
It contains improvements for the picture Viewer:

• better scaling
• (some) faster loading
• exif orientation support
• pause resuming slide show
• colour tuner
• code reorganization

All patches are still against cvs of 2007/11/18, rebase to newest will follow. A dongle is included.

Feedback is highly welcome.
Regards
Andreas

On a PC I can stream an mpeg2 stream from a dreambox by doing:

http://192.168.2.7:31344

And it will play whatever is on the TV.

Is there a way to do this on Vomp?

As soon as there is a video media player available (still needs work in the media player) this could be an interesting option.
At the end this would be more efficient then to go trough the server.
What about having a small vompserver on the dreambox?
OK currently does not make much sense - but if the mediaplayer could play videos it could be integrated on the server side to access streams - then no additional server would be necessary.

Could I create a playlist and try and play it?

It's on the todo list for the mediaplayer (just after video...).
Regards
Andreas

Hmm,
interesting discussion...

I got the impression that the Vomp Media player browsed a file system (NFS mounted or locally stored)
If it was then djmount would have made it transparent to Vomp whether UPNP was used or not, since the interface to djmount is the file system.

OK - would not be too difficult (at least in the moment) to add some code to make the media player also access files on the client side.
Needs some thinking how to be configured - but in the moment it's just 3 functions:
- list a directory
- open a file
- get a block from the file
The more tricky thing would be how to set up the lower layer part.
What I'm afraid of:
If the djmount (didn't deal with it until now) would be slow/ would wait when searching it would block the whole client. When I was using this with mvmpc (and my DS101j which has an UPnP server too) it was really annoying.
@AndersF - if you would like to try something we could make a small interface at the client where code could be plugged in for local file access.

Are you sure there is not multiple protocols, like a telnet/text based protocol for listing media files and a binary protocol for the actual media access?
I believe I have seen a telnet interface in the Vomp code!

At the end the protocol is all binary.
Just look into vdr.cc on the client side - there you can find all the code.
Basically it's always a (synchronous) request from the client awaiting a response from the server. No parallel transfers in the moment - so you always have to deal with "small" blocks - but this is OK for easy error detection.

How about setting up the UPNP protocol on the server plugin? Should also do the trick, but for sure a bit more tricky than on the client.

Would be possible of course - but I would not really like it due to the doubled network load (and again - the same fears) - so maybe this would need separate threads and all the stuff to make it still responsive.
At the end my favorite solution would be some code on the client if we can assure that the vomp will not get blocked from strange things with the media servers...
Currently I'm working on the picture viewer (speed, scaling, colour tunig and exif orientation) - the next will be parallel pictures and audio, then video.
Everything  else (from my side) afterwards.

Regards
Andreas