Dear all,
I am experiencing VDR errors when loading EPG via SVDRP. If the EPG data to be loaded is larger that 3 MB then VDR silently drops the SVDR connection.
Everything is fine if the data is truncated to fit 3 megs.
I have to admit that I am still running VDR 1.3.31, so this issue might have been fixed in more recent versions.
Regards,
Pjotr
Pjotr Kourzanov wrote:
There is an issue if the EPG download is too slow. In that case, the VDR watchdog timer may restart VDR to bring back VDR to life. You can try to increase the watchdog timeout value. VDRAdmin-AM can also read the epg data directly from the /video/epg.data file, avoiding the lengthly and slow SVDRP download.
Cheers,
Udo
Udo Richter wrote:
I have recently sent the attached patch to Thomas Koch tom@linvdr.org. It dramatically speeds up getting EPG information from VDR.
Klaus
En/na Klaus Schmidinger ha escrit:
...
I have recently sent the attached patch to Thomas Koch tom@linvdr.org. It dramatically speeds up getting EPG information from VDR.
I think the OP problem is the reverse: getting EPG data into vdr, not out of it.
Bye
Luca Olivetti wrote:
Indeed, I was referring to the problem of loading the data to VDR. Tweaking the watchdog timer looks like a dirty workaround to me - the value depending on amount of EPG data to be loaded divided by the speed at which this data could be transferred to VDR (do we assume loopback access, or ethernet? maybe wireless or WAN/VPN access?).
I have neither investigated the problem deeper yet (just found a way to split the EPG data into parts), nor looked in the source code. Is it so difficult to convince the watchdog that while SVDR thread is busy it is actually doing useful work?
Pjotr
On Wed, 10 Jan 2007 23:48:38 +0100, Pjotr Kourzanov wrote
SVDRP is not implemented as a thread. Processing the SVDRP interface is part of the VDR main loop. The problem is that if you are uploading EPG fast enough, the SVDRP code will remain in cSVDRP::Process() until you're done. So the watchdog timer will not be refreshed and the watchdog eventually fires.
There are two possible workarounds: 1. increase the watchdog timeout 2. take a short break from time to time while uploading the EPG. The "while (file.Ready(false))" loop in cSVDRP::Process() has a timeout of just 10 milliseconds. With a sleep of 100ms you should be on the safe side, as you still need to take into account that network traffic is buffered on both, the client and the server.
Cheers, Frank
Hi,
I heard that in new versions multiple SVDR connections are/will be allowed. Does it mean that they will be then implemented via a separate thread and my problem is solved?
Frank Schmirler wrote:
Well, as I said earlier, these things look like dirty hacks to me. For now I will just continue using my own dirty hack by splitting the EPG into parts.
Pjotr Kourzanov wrote:
Pjotr,
How did you split the information up?
I have a 17MB xmltv file which I would like to upload into VDR.
Is it possible to adjust xmltv2vdr.pl to split the xmltv epg into parts too?
My python knowledge is limited, but I am willing to have a stab at it.
Rob Davis wrote:
See script attached (given stdin, creates epg.[0-9]* files of ~3megs, without overwriting).
Maybe. I found xmltv2vdr just too slow - it took ~9 hours to output 17MB of VDR epg.data. The XML was btw. ~54MB.
My python knowledge is limited, but I am willing to have a stab at it.
xmltv2vdr.pl is perl:-( But if you know AWK, I've posted my version of xmltv2epg on this list that takes ~40 minutes on the same data:-) Also, it takes extra info like credits into VDR's epg...
Regards,
Pjotr
#!/usr/bin/awk -f BEGIN { max=3*1024*1024 if (!base) base="epg." n=1 advance() size=0 } /^[CEeTSDX]/ { size+=length } { print > base n } /^c/ { if (size>max) { advance() size=0 } } func advance() { while (!system("stat " base n " >/dev/null 2>&1")) n++ }
-
Frank Schmirler -
Klaus Schmidinger -
Luca Olivetti -
Pjotr Kourzanov -
Rob Davis -
Udo Richter