Messages

If you connect to the vdr SVDRP port (default 2001), with for example nc/telnet, and run the LSTR command you get the output for all recordings that vdr has found.
Current vompserver-plugin uses the same listing and sends all entries in one string to the vomp-client in the same order as it appear in the listing from vdr.
If you have the problem with to small buffer for the recordings, the recordings you see in the vomp-client should be a subset (top half) of the list of recorings you got from vdr.

And as hondansx write you only have to edit mvpclient.c and recompile the vomp-server plugin for vdr against the current vdr installation, probably move the plugin to right place and restart vdr. No changes needs to be done at the vomp-client).

How you do it and where you find the code depends on the linux-distribution. On gentoo I downloaded the source code for both vdr and the vdr-vompserver-plugin, changed the code, compiled the plugin, moved the plugin to /usr/lib/vdr/plugins and restarted vdr.

//M

Hi,

As I understand it the problem can be either

1) Timeout problems
If it take more than 10s (default) to get the recordings from vdr (vompserver), vomp-client gets a timeout and disconnect from vdr (vompserver). When you reconnect with the vomp-client you should have all recordings (if not 2 apply below).

2) Recording lengths is larger than default buffer (50000 char).
If you name your recordings with long names and /or have a large directory tree you might exceed the default size of the buffer thats holds names and "path" for all recordings.


I solved #2 by changing UCHAR in mvpclient.c (just to be sure I changed all occurrence in the file), and modify the appropriate if –statement for the function MVPClient::processGetRecordingsList in the same file

int MVPClient::processGetRecordingsList(UCHAR* data, int length)
{
...
UCHAR* sendBuffer = new UCHAR[500000]
...
if (count > 490000) break;
....
}

By thy way, thanks for a great software Chris

Regards
/M