Messages

It sounds like the client is exiting to me. If the screen ever goes black like that the client is waiting for data transfer from the server. If that doesn't come, and you press the back button, the client will return to the menu after the TCP timeout time. Which is either 10 or 30 seconds I think. If pressing back and waiting doesn't do it, the client is probably dead. The only other thing that could cause unresponsiveness is threads deadlocking, but I don't think that will happen playing live tv.

I have thought about making an option to vompclient that makes it boot up and show a message like "Sorry, I crashed" etc. Then the startup script could loop and run vompclient again. But there are negative points about that idea too. Hmm!

Radiofreak, you are right, developing both client and server myself allows me to do pretty much anything I want that is within my programming ability... (And the daft limitations of the MVP). However it does mean that development is slower because I'm working from scratch. It's swings and roundabouts, for anyone who understands that expression! I have added your startup idea to the Request For Enhancements list on the SourceForge site. My views on the general media player aspect of the MVP are already on here, but I have to say that the possibility of playing a DVD through it interests me. Which is a bit stupid as it would be the most complex one to code with all that menu system DVDs have. Anyway, that's a long way down my list!

First I want to say, that I'm impressed by the work done here. Vomp is actually my favorite - I tried all others, and none satisfied me more than vomp 
Very very very good work - faster boot than any other MVP client, fast connect to server. Stable for me with some minor faults (picture disruptions by using forward and backward buttons).
Some things that may be improved if there is time for it: a) time to load channel list is very long (for me: 25 seconds [1245 channels, because I'm too lazy to work on my channel list - just copying]) - b) vomp dies if channel is not available - c) initial volume is always max on starting (startup parameter ?) - d) channel switching while showing OSD
But I agree with Chris, there are things much more important than these to work on (EPG..).
Again - great server - keep on.

@Hoochster: there is a way to make it work without a full dhcp-server. I use the standard dhcp-server of my router and then I use mvploader to provide the dongle for the MVP. Works like a charm. Here the link for this piece of software: http://www.vdr-wiki.de/wiki/index.php/Mvploader

My config: gen2vdr-RC3, vdr-1.3.27, dongle 0.0.8, FF-DVB-S 1.5 & 1.6

Thanks for the comments, always nice to hear someone likes it!

As for your could-be-betters:
A) 25 seconds is ridiculous. I will look into what is happening.
B) It shouldn't die if the channel is unavailable. Does it just go to a black screen? What kind of unavailable is it? VDR recording something else, channel not being transmitted?
C) Initial volume is something that will go in as a configuration option. That one is listed on the SourceForge RFE too
D) When I get the EPG into that box I will make OK change channel. Otherwise press back to get rid of the box and then change channel. New remote users will have enough buttons to be able to have the option of scrolling through the EPG or changing channel.

Wow, so much to reply to, and so little time... The issue about DHCP and booting the MVP, what does the MVPLoader actually do? The problem with routers giving out IP addresses is that a router can't tell the MVP the IP address of the TFTP server. I havn't experimented with what the MVP does if this information is not there, but it sounds like it does something?

Unless the MVP does something intelligent if it isn't given a TFTP server address there's nothing vomp can do about it.

Yes, YAEPG looks good. I think that is what I will work towards when I get onto the main EPG page. I know that the MVP can do quarter screen video and have the OSD on the rest of the screen so yes, that should be very possible.

And wow, that VDR skin looks nice. It could be a long time before vomp looks that nice!

I only use VDR as a backend recorder, actually it runs on a headless big noisy server box in another room. I have always used only the MVP to watch its recordings. But just out of interest, how is it possible to use the generic tv applications and still see the VDR gui? Or am I just missing something here...

I don't have a fully featured receiver card so I've never seen the VDR frontend. What is YAEPG?
I am trying to get a fairly decent EPG system working because I would like to interact with the VDR timers one day in the dim and distant future. I would like to be able to duplicate all the functionality of the web LinVDR admin system into vomp. As yet I can decide how to do EPG best for the MVP. I was pleased to find that 24 hours of a single channel including descriptions is just a few KB which is nicely manageable for the MVP. I am going to get the current on screen box working, and then go back to widescreen. Which is a PITA. I would have done it already, but the video chip just seems to make up its own rules about when to do widescreen and not. I actually moved onto this EPG system which I had been dreading for ages.. that's how bad it was

I am currently working on getting the next 24 hours of EPG for the current channel displayed in the on screen box that appears over Live TV. I have most of this working now, I just need to sort the data and it's pretty much done. That's only one part of the EPG display though, a now/next page would be nice but is not a priority, and a full guide page would be nice, but I think the GUI code might need some attention first, before I could do that. At the moment I am mainly working on the caveats list on the vomp web page so that all types of TV/signal etc can actually work. After that there are the bug lists and feature request lists on the SourceForge page. And after that, who knows... I still want to stick to the clean set top box for VDR approach, so things outside that scope are very low priority for me.

You are reading 0.500 ms as half a millisecond I hope... Not half a second?! There's nothing even close to wrong with half a millisecond ping times. And for comparison, I get about 0.320 ms to the MVP and about 0.130 ms to a normal PC. So that says the MVP is a bit slower but nothing to worry about!

The MVP is set to 100Mbps half duplex, yes. Something about the network chip being a bit underpowered and having small buffers compared to a standard network card, so it's actually disabled down to half duplex by the kernel driver for the chip. Not that that is a problem, 100Mb half duplex is fine for the MVP as all the big data transfer is one way. As for the bandwidth used, UK TV channels seem to transmit anything between 2Mbps to 5Mbps, so compared to the (theoretical ) 100Mbps available, there is no problem there either.

Rene, if you are using dongle 0.0.8 then the big disruption problem should not exist. Though there are two other issues with the software that cause very slight picture corruptions. The first is on live TV only - prebuffering doesn't work yet, so for the first minute or so the MVP is hard up against the incoming data and occasionally pauses briefly as it runs out of data. This resolves after about a minute or two when the MVP gets far enough behind the incoming stream to always have data available. The second is a demuxer bug that we are still working on, but this should only cause very small regions of the screen to disrupt momentarily, about once every 5-10 minutes.

Hi.

The vomp plugin requests live streaming from VDR at a priority of zero, if you get the channel unavailable message it means that VDR has refused the channel at that priority. Or this is what I am hoping to happen! Do you have a fully featured card that may be displaying a channel with VDR itself?

As for upgrading the server, only sometimes you will need to update the server. If its necessary when I publish a new dongle I will always try to remember to put that in the release announcement.

Haha yeah, Mplayer by tomorrow, well you'll have to be quick about that one, won't you?

Yep, rewind doesn't do anything yet. That would be because I havn't worked out how to do it yet I have to say though that with all the skip buttons (inc yellow and green for about 10s each way) I find I rarely want to use rewind. But I will get it working one day.

I've posted the dongle. Let me know what's fixed and what's not!

In this dongle:

The volume control has been altered - it is half as sensitive now. Before it did most of the work on the top few bars.
More data is now scanned for different audio channels in a stream - it was possible for it to choose the wrong audio track sometimes.
Select lists now have columns, this fixes directory names to be in-line with recording names in the recordings list.
Select lists can now have an unlimited number of entries allowing more than 500 recordings/channels to work.
One demuxer bug fix, fixing audio and video corruptions on some channels.

Good luck!

The demuxer bug is fixed, that will be in dongle 0.0.8 as well.

Yes, the GUI is in the dongle. The source code to the client program is in SourceForge CVS just as the server is - the module is called "client". It's not just as simple as that though, if you want to compile it you have to set up a cross compiler environment, but I have documented how to do that on the website.

As for the crash, I have fixed it, the fix will be inlcuded in dongle 0.0.8, which should be today or tomorrow.

I just put your channels.conf into my dev vdr and got the same crash. I traced it through to a 500 entry limit on the select list gui code 

So later I'll err, fix it