Messages

Ok, an update on the radio situation for anyone watching this thread. I am not suspecting sync problems as much now, I think the problem is that the radio data coming from the vompserver plugin is in the wrong format, but not bad enough so that the MVP can't play it at all, just enough so that is jumps and starts and makes a mess. Trouble is, I now need to edit parts of the vompserver plugin that I didn't write to make it output radio in the correct format, and I don't know just when I'm going to get the time to do that at the moment.

I'm not 100% sure on all this but it's my best guess yet.

Well believe me, I'd love to fix it! But errrrr... I don't really know what's going on here. I have one suspicion which someone is testing for me (I hope), if it isn't that, then I'm lost. The shortest timeout in the client is 10 seconds I think, but that should be enough for VDR to do something and send back the results. I have no idea how moving from 10Mb to 100Mb could make any difference, unless your network is almost saturated all the time!

What version of Linux, and what version of the kernel is everyone running on the VDR server?

Glad you got that one sorted, but no recordings being listed is very odd.. The client asks the vompserver plugin which in turn asks vdr directly. I have no idea what could cause that, if anyone else is reading this thread, have you ever seen anything like this?

I think this should already work. No vomp software operates on port 16882. After the vomp dongle is downloaded and run in the mvp, it sends a udp broadcast on port 3024 to find the vompserver, then it connects to it again on 3024. All you should have to do is change the dongle file supplied to the mvp and you can run something else.

Most of it is simple (most of it is done!), but I've had a couple of goes at this now and I have only got it to play audio badly. It seems to take a large lump of audio, start playing it, but then it skips through it as if it's trying to catch up with something. After a few seconds it gets to the end of its buffer and it is hard up against the incoming data, so the sound is full of holes.

So I need to work out what it's trying to sync with, or work out how to disable it, or see how mvpmc does it.. Something like that.

Great, I'm glad that all works. As you say it's basic at the moment but hopefully reliable. I think getting radio working is the next obvious thing, but the way the MVP does prebuffering is quite odd! After that, who knows...

At that point the MVP is UDP broadcasting on it's subnet for a VDR server running the vompserver plugin. The fact that it's not connecting means that it's not getting a reply from the vompserver plugin part of VDR. There are quite a few things that can cause this... Is vdr definitely running with -P vompserver ? Are they both on the same subnet? Is the linux box firewalling the ports required? (3024 on udp and tcp), and possibly other reasons. So what do you think, do any of these sound possible?

Now I didn't exactly say that

It is on my wish list, but I havn't really got that far yet.

This version is only worth downloading over 0.0.13 if you have multiple VDR servers.

A segfault is fixed if the program tries to display the "select a server" box.

A segfault is fixed if you press ctrl-c on a console when running vompclient -d when the "select a server" box is displayed.

Also, experimentally for this version the program will now daemonize if not running with -d. This allows the init scripts to complete which gets rid of a task or two. I don't think this should make any difference to the operation of the client though.

Make that two unrelated tricky little segfaults.. Anyway, done now!

Slow in the making, but hopefully good quality

Dongle 13 is now available. The automatic RGB / composite scart switching that I broke in dongle 12 is fixed.
A segfault when going to standby if no server was found is fixed.
A segfault when deleting the last recording in a directory is fixed.

Well I'm back from a week away now, so I can get things moving again. I think I have found that the new modules I used for dongle 12 cause the problem with the switch back from RGB to composite. When I tested it my TV went to composite, but as I could switch it manually to RGB and it worked, I assumed it was my TV playing up as it's getting old and senile. Seems not though!

So, I'll be releasing a new dongle probably tomorrow when I have tracked down an unrelated segfault.

Yeah, I think it's the lowst numbered audio channel in the stream that is used. This seems to work for UK DVB-T. As dave says, the rest is WIP.

No, fixed-address is the address given out to the MVP. Server address is something different, it is the next server for the client.

Glad it's working!

I don't really see how those extra lines could make much difference in the dhcpd.conf but hey, if it works now...