News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

All recordings are not listed

Started by KarZan, September 30, 2007, 19:18:11

Previous topic - Next topic

KarZan

I happened to notice that when I have an external harddisk (usb) connected to vdr server and mapped to a directory under vdr recordings directory womp does not show all recordings on that drive/directory. I tried to search for if this is a known feature (bug) but could not find anything.

As said I have an external usb drive which has 90 some recordings on it. There is also one tv-series there which has 60 some recordings. Womp shows only these recordings and no others on the same disk. The others are shown normally on vdr but not on womp.

BvompM

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

KarZan

#2
Actually I had 2 usb drives connected to vdr server which made the total recording size roughly about 700GB. So there is a lot of recordings :) I noticed just now that there were missing recordings from here and there when the recordings were sorted alfabetically. So I assume that the cause may be one or both of those you mentioned. If I understand correctly 2 should only apply to cases where the length is too long. I might have those but the funny thing is that I had such recordings on the list that are deeper in the tree structure while missing some that are higher. So propably my problem is timeout which most likely is due to the amount of my recordings. I did not try reconnecting but I did unmount those usb drives and now I can see recordings that were missing.

Just out of curiosity. You wrote that the client would disconnect in case of timeout. Would that mean a real disconnect where the client starts over and goes to main menu? If so that did not happen. Also the list of recordings comes in about less than two seconds and as said there are recordings missing from the top level also. That is recordings that are on the vdr servers harddisk not on the usb drives. And to clarify more those missing recordings can be seen when the usb disks are unmounted.

And I would also like to thank Chris for an outstanding piece of software.

hondansx

#3
Thats an interesting point as BvompM said.
I changed the timeout to 20s and the default buffer to 90000 char.
Maybe someone can test it.

Walter


GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

KarZan

#4
What do I need to get this tested? Environment? Compiler? Where's the source? Edit: I assume I need to set up development environment :)

Btw, same problem can be seen with windows client. Could this mean that the problem lies in server side?

hondansx

You have to patch the serverside against cvs and recompile.
That should do it.


Walter
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

BvompM

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

KarZan

Finally I had time to test this.

Copied CVS version which seemed to have those changes allready from hondan diffs  so no patching needed. Compiled the server and copied it to /usr/lib/vdr (which is used in fedora) and restarted vdr.

Then I restarted client also just to be on the safe side but there were no change :(

Timeout is propably not the reason because it takes only a couple of secons to get the listing on the screen.

LSTR shows recordings that are not seen on the client.

\\Kartsa

Chris

Hello, if it only takes a couple of seconds to get the list then you are correct, it is not timeout issues. It is most likely the recordings data buffer in the plugin. You said that you didn't patch the server from CVS? Check that again, because the current vompserver CVS code is still at 50000.

If increasing that number doesn't fix your problem then I have no idea what it could be. I have never had trouble with that limit myself, but with long paths to recordings maybe it is possible to get there.