Messages

dingo35, Marten, thanks for your efforts on the VDR 1.7 development patches, good work!

As for the Yaris version, thanks once again to Walter for all your work. I do think we can sort something out about getting the two versions closer together.

I am going to make a release of the code as it stands soon, just to attempt to draw a line in the sand and have a new base to work from.

stu-e: I have added that to the server Makefile, thanks for pointing it out.

I have a D3A, the label on the PSU says it's probably capable of 1.66A at 6V. So I would recommend a 6V supply with at least 1.66A but probably aim for a 2A or more. Having more amps is not a problem.

Edster: Mine starts playback in just over 1s. Granted, I have a faster server than you, but all it's doing in this case is file serving - network latency and disk performance would be far more important than the cpu speed. Can you post a vomp client log from the point where you press ok or play on a recording up to it starting to play. (Done by telnetting into your mvp, run killall vompclient, run vompclient -d and paste back the relevant bit).

If that box is modifiable in a similar way to the current MVP then this is good news.

Harry: My testing of BBC HD shows it is about 2MB/s.

Hi..

It looks like the MVP is being given an IP from your DHCP server, but then it isn't asking for a dongle from the TFTP server.

Is you server "gustav" still on IP 192.168.1.200 ?

As root, run the command

Code Select Expand

lsof | grep UDP

and look for a line like this:

Code Select Expand

inetd      2923        root    4u     IPv4               6960                   UDP *:tftp

.. to prove that your tftp server is working.

Post back your results.

Well spotted... I started a KDE 4 session on my normal user account, went back into gnome and now qtvomp works!

Just out of interest, do you mean you have got the binary running in a gnome environment? Albeit with all the KDE stuff installed?

Fixed.

Isn't it "-s"? Or is that an earlier version of the code?

Oooh, quiet in here...

[Requirements:]

Philipp Müller has created QtVomp, a Vomp client for Linux. He would like to annouce the following.


This is the alpha 1 release of a Linux desktop client for Vomp.

Only the source tar ball is provided, so you need to compile QtVomp by yourself.

Requirements:

• Qt 4.4
• Phonon-Xine-Backend out of KDE 4.1 (only runtime dependency)
• VDR running Vompserver-plugin 0.3.0
• Installation instructions are in the INSTALL file

Supported features:

• Channel list with EPG entries
• Playing live-TV
• Playing recordings
• Playing MP3 files

Usage of the client:

The structure is similar to the normal Vomp usage, so it should feel familiar. Beside of the normal behavior of Vomp and common mouse handling of lists, buttons, etc following is not so obvious:

• Channel switching is done with Page Up/Down
• Double click on the video area switches in between full screen mode and windowed mode
• In full screen mode ESC returns to windowed mode
• In full screen mode Alt-F4 is deactivated

Known limitations:

• QtVomp cannot find the VDR server automatically, when run on a PC where an instance of VDR/Vomp is running. Use the command line argument -s <ip-address> then.
• Recordings don't support any jump forward / backward in the file, This is a "bug" in Phonon in combination with the VDR recordings format
• Some MP3 files don't play (Phonon issue)

Please report everything - success, failure, ideas to the forum for open discussion.

If a file doesn't play or no output in general, please test as follows:

• Have a look into the README file, some exceptions are explained in detail
• Does the file play with Dragonplayer? If not it is a Phonon issue.
• Is the Phonon-Xine-Backend default (see KDE System Settings - Sound - <tab> Backend)?

Download

http://www.loggytronic.com/dl/qtvomp-0.3.0-alpha-1.tar.bz2


Philipp Müller

It wouldn't be technically difficult to do, but it gets a lot more complicated when you consider how to design the UI part of it. Do you ask the user every time whether to save to local or server level ... Then ask again at resume time... Or do you enforce it per server - but then where do you put the UI for that selection? What happens when someone changes the master selection? As usual with ideas for vomp - the back end would be not too difficult to do, but the UI would get complicated quickly, much reducing the ease of use that I like to keep in vomp.

Unfortunately this is currently not possible - the resume positions are saved in the per-mvp config files on the server. Is there anyone else that would want this to work the other way around?

googles - thanks for the patch. It is included in cvs and will be in the next version of vomp. Can I put your real name in the copyright and credits file, as I'm not sure "Copyright Googles" conveys the correct message

Crashing: I also see this frequency of crash, but in my case most of the time it locks up the MVP entirely which means it's a crash in the kernel drivers or hardware. I see this as a fault in a layer that is out of our control.. Now maybe there is something vomp is doing which the hardware doesn't like, or maybe there would be a change to vomp possible that would prevent it, but with the MVP locking up entirely it's very difficult to debug.

TCP window size: What type of MVP was this with?