Messages

It certainly sounds like there is something strange going on there. And yes, you are right it isn't a full reboot, it just restarts the process of getting an IP/TFTP etc. The number of blocks tells where the MVP is in the process, not that I can remember what they all mean...

Do you have another DHCP server on your LAN? A broadband router for example? Any strange firewalling going on with the Linux box? Did the Windows software work properly?

I'm scraping for answers now......!

The software will no longer switch the aspect line if the TV is a 4:3.
16:9 on 4:3 letterbox done

And many many internal changes. If you see any weird happenings with the menus or any on screen display stuff, please let me know how you did it.

Yeah, the only thing that could make a difference I am seeing here between the two configs posted here and my own is that there are quotes around the tftp file name. But if dhcpd doesn't complain about that I doubt it's a problem. In between the two DHCP requests and offers does your MVP reboot? How many blue blocks does it display before rebooting?

Just for info, the log looks ok as far as it goes, the next line in your system log should be a tftp server log line. I'm surprised it's not there. Is your distro a debian based one? If so there might be more detail in /var/log/syslog rather than messages.

  Glad its working now.

I could only get the channel the main vdr was on  so that solved the channel thing but I can only watch for about 5 minutes, then dongle crashes and says "channel not availible" also it does the same on recordings to??

Well I don't understand this bug really, but could you recheck the part about it saying unavailable on recordings? In the code there is no way the mvp could put up the blue box saying unavailable when you play back a recording. Not unless something is going hideously wrong! 

Thanks.

Ah yes, I was having a stupid moment there. The MVP could get it's own MAC address and send it to the server I think. I was thinking on the other track of the server auto detecting it.

I appreciate a VDR board might be a better place for this, but I'm a bit stuck for time so I'll just pick your brains instead!

My VDR has been running for a couple of weeks now, and the top command reports that the VIRT memory size is about 2GB. On switching a few more fields on in top, it seems this is coming from swap space. Now I don't have 2GB of memory in any form, I have 512MB real memory and 512MB swap. According to the free command, I am using 109MB for programs for the whole box, and only 84k swap space is in use.

So, obviously something is messing with the memory reporting. I just wondered if anyone else has seen this problem, and/or seen any solutions on any other boards about it.

Oh, this is VDR 1.2.6 by the way. And I only spotted this problem because I have been writing a C++ w/STL program for work which is doing the same thing. Both VDR and this program are written in C++ using STL. Hmmmm, a clue?!

Yeah, I thought aboubt that after your last post. But then that definitely restricts the mvp to being on the same subnet as the server. (Whereas it is restricted effectively now, but those restrictions could be overcome one day). What dhcp server do you use? Surely you use a linux one so you can serve out the tftp file name?

Yes, I thought the VFAT compile option did exactly what dave said, I am stumped as to why it would alter live tv in any way!
I will have to investigate that one!

Hmm, odd. You have a fully featured card don't you.. Can you watch the same channel that the main VDR is watching?

Ah yes, that would cause problems. Do you have a way of serving the MVP a static address?

Yeah. I left that because I need some timed event system to run the clock, and then it needs to work out whether that area of the welcome screen is the top most box, etc etc, blah blah. I shelved it until at least after this gui rewrite - as there is now at least real memory allocated for each window. I still need some z-order code and an event system though. Rather complicated for just a clock!

In the VDR server config directory there is a directory called plugins. In there the vompserver plugin will save vomp-(ip.address.of.mvp).conf.

Do other options save their settings? Does resume recording work as expected? Everything writes to that file.

dave, I committed a large chunk of the gui rewrite last night, I don't think it will drastically affect any translation stuff but there might be some cvs conflicts. Just to let you know..

BTW, the gui rewrite isn't finished, it's just in an intermediate working stage

Haha, ok ... Maybe it's the case that if the TV is 4:3 the scart switching should not be done. I wondered about that while writing it, whether I should switch it anyway - as it turned out it was easier to leave it switching since I had no reason not to. Maybe I'll meter my real freeview box to see what it does...