Messages

Hi Jürgen,
basicall you have to add some code the the script to handle the particular extension of the flac files.
So 2 steps:
1. add the extension to vomp.conf to be handled with a script
2. add something to e.g. test.sh to call mencoder with your file (just look e.g. how wav files are handled) - maybe simply add a function

Code Select Expand


handleFlac() {
  mencoder ....alotofoptions -o $FIFO "$1" 2>/dev/null &
  MPID=$!
}

and insert somewhere at around line 353ff:

Code Select Expand


flac|FLAC)
  createFifo
  handleFlac "$1"
  startReader
  waitFkt
  ;;


For testing call test.sh with the name of a flac file and pipe the output to some player (e.g. xine).

Regards
Andreas

After a long time....
not sure whether you are still working on this.
Currently for audio there is a fixed number of retries for reading data - in audioplayer.cc on the client side - MAXTRIES (counts in ~100ms units). This is set to 50 - meaning app. 5 seconds until the stream gets closed.
So first you should switch of the prebuffer delay (waitFkt without the "1" parameter).
But I guess you need at the end more then 5s as the wget takes already 6s.
So a dirty trick (if you cannot change the client) would be to feed initially some silence- sound into the pipe that lasts for a short time - the 5s start again after an receive - so maybe:

Code Select Expand


http-radio)
    fn=`echo "$2" | sed 's/\.[^.]*$//' | sed 's?^ */??'`
    createFifo
    cat silence.mp3 > $FIFO &
    bgpid=$!
    convertradio_playlist "$fn"
    kill -9 $bgpid
    startReader
    waitFkt

not tested - but only an idea...
The silence.mp3 should be only the time you typically need for the wget+setting up mplayer-5s+someSecureAddOn.

BTW: can't you use mencoder to avoid the second FIFO? - would make converting easier...

regards
Andreas

after long time:
sorry: unfortunately client specific configs are still not there...

Regards
Andreas

Hi rdoac,
in principle you can already do that (not really elegant...) - just activate streamdev-server and create a list with the channels+urls to be read with the mediaplayer.
By having some strange extension you can easily pipe them through mencoder.
It's some overkill:
vdr-streamdev->TCP->wget->PIPE->mencoder->PIPE->vompserver->TCP-vomp
But anyway it works (tried this for fun some time ago).

It's not really seamlessly integrated...
If you would like to do some hacking on the server side...
- increase the number of channels for the mediaprovider to e.g. 3
- for the sending side maybe a simple TCP-socket-server just sending out the activated stream
- plugin an appropriate call to some mediaprovider code (having the socket address encapsulated into an url)
But it's some bigger work

Regards
Andreas

@Lutz,
which version do you use? cvs?
I would suggest to goto vdr portal and use this version - probably the cvs is still not on the latest version.
http://www.vdr-portal.de/board/thread.php?threadid=79474&hilight=vomp

Sorry for this - but I cannot write to cvs and have to wait until Chris merges everything...
If things still not work, logs would be interesting - client and server (a lot is discussed at the vdr portal thread - although in german).

Regards
Andreas

@Lutz:
How did you play the files at vomp?
If you used the media player some logs would be interesting.

Regards
Andreas

sorry - currently not really much time to check...
Please do simply omit the call to duplicateHeader in demuxermedia.cc (not really critical for functionality).

regards
Andreas

Sorry - I forgot the demuxermedia...
Attached here.
Regards
Andreas

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

Today I checked the cvs for media player stuff that is still missing.
I attach 2 patches here - one for the missing corrections in the mediaplayer, the other one for the tcp stuff.
Additionally there are still some missing changes in boxstack.cc - I also attach a patch here - not all of it is really necessary, but at least it creates a working version.

Regards
Andreas

@davep,
hmm - very strange - never saw before that vompclient was really able to crash the mvp.
Difficult to reproduce on my side (especially as I do not run the latest CVS currently).
Waht it does (from the debug output): It switches the feeder (audio feeder) from running to stop via afeed.stop(). Not sure whether something can go wrong there.
maybe it could help to call afeed.disable() before stop (at around line 114 in audioplayer.cc) :
{
afeed.disable();
afeed.stop();
}

Regards
Andreas

@davep

The best that can be done for portrait photos is if the pictures use all of the available screen height.

If you display jpegs via the converter (test1.sh) it tries to fit the picture to the screen the best it can by keeping the ratio.
I'm still investigating if there is an easy way to do this at the mvp...

Regards
Andreas

@davep,
thanks for the examples...
But maybe the problem is still not really clear to me.
Do you run on 16:9 (I guess yes).

What I feel:
If you run everything in 16:9 the pixels are not really square anymore (as assumed for 4:3).
At the end we output still 720x576 (for PAL) but in reality it goes to somewhat like 1024x576 so in horizontal direction every pixel is expanded by 1.4.

If you want to try something and if you are running the latest version and have picture display via test1.sh enabled, you could make some replacements in test1.sh:
around lines 236ff (in convertPicture.sh):

Code Select Expand


238: fopt="-geometry 1024x$3"
...
245: gm convert $rtopt $fopt  "$1" jpeg:- | gm convert -geometry '70%x100%!' jpeg:- jpeg:- 2>&1 &

And see how this looks like...
If this is OK, I have to figure out, how I could do this scaling on the vomp side.
Alternatively we could switch picture display to 4:3 (but then it depends on your TV).

Regards
Andreas

@rdoac,
just uploaded a patched script at http://www.wellenvogel.de/software/vomp.

Thanks for the hint..
Regards
Andreas

@davep

Can anything be done about the aspect ratio of images? If I display images taken from film transparencies (3:2 aspect ratio), they appear on the screen stretched into the 16:9 format. For landscape photos this doesn't look too bad, but portrait photos appear nearly square.

Do you have an example for me?
Not really sure what to do there - I use the settings the menu is in for displaying pictures. Maybe for 16:9 this needs some changes.
It would be helpfull if somebody could give me some hints how it should look like on 16:9 tvs (mine is currently 4:3 ;-().

Also fast-forward mode is enabled when playing mp3 files. This makes a terrible noise!

I agree - the only short term solution would be sto disable this.
Maybe somebody knows how to do frame skipping for ff to make it sounding "acceptable"...

regards
Andreas