Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems
On 22.08.2009 23:03, Simon Baxter wrote: >> On 22.08.2009 00:51, Simon Baxter wrote: >>> Hi >>> >>> I use xmltv2vdr to process .xml EPG listings and populate VDR. >>> >>> VDR seems to be processing the EPG (via SVDRP) into and across two >>> channels. There's no error in the xmltv2vdr - seems to be a VDR problem. >>> >>> Example: >>> here's a snippet from "./xmltv2vdr.pl -x listings-sky.xml -c >>> test.channels.vibe -s >>output" >>> >>> C C-182-5-504 Vibe;T >>> E 8270 1250904000 3000 0 >>> T Smallville >>> D Clark is amazed when a pesticide magnate somehow convinces Jonathan to >>> sell the family farm to make way for a new plant. >>> e >>> E 8320 1250907000 2700 0 >>> T Smallville >>> D When Clark rescues his classmate from harm during an electrical storm, >>> they are both struck by lightning - resulting in all of Clark's >>> superpowers being transferred. Lex confronts Clark about his powers. >>> e >>> c >>> C C-182-2-212 Prime TV;T >>> E 8300 1250905800 1800 0 >>> T Chequered Flag >>> D Czech Moto GP Highlights - Moto GP returns after its summer break with >>> the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals >>> Jorge Lorenzo and Casey Stoner. >>> e >>> >>> >>> but when I do a "LSTE at 1250905800" >>> >>> The "Chequered Flag" program is appearing in Prime and Vibe: >>> >>> 215-C C-182-5-504 Vibe >>> 215-E 8300 1250905800 1800 0 FF >>> 215-T Chequered Flag >>> 215-D Czech Moto GP Highlights - Moto GP returns after its summer break >>> with the Czech GP at Brno and Valentino Rossi holding a slim lead over >>> rivals Jorge Lorenzo and Casey Stoner. >>> 215-e >>> >>> >>> 215-C C-182-10-1004 Prime TV >>> 215-E 8300 1250905800 1800 0 FF >>> 215-T Chequered Flag >>> 215-D Czech Moto GP Highlights - Moto GP returns after its summer break >>> with the Czech GP at Brno and Valentino Rossi holding a slim lead over >>> rivals Jorge Lorenzo and Casey Stoner. >>> 215-e >>> 215-c >> >> The channel you entered EPG data for was >> >> C-182-2-212 Prime TV;T >> >> while the one listed later is >> >> C-182-10-1004 Prime TV >> >> >> Are you sure that this entry has not been in there for "C-182-5-504 >> Vibe;T" >> before you ran xmltv2vdr.pl? >> >> Klaus > > I think I've now fixed this... > > I did have these multiple entries in the xmltv2vdr.channels.conf file : > Prime > TV;T:594000:C0M64:C:6900:1312+1212:1412=eng:0:606:212:182:2:0:prime.sky.co.nz > > Prime TV_A:189250:C0:C:0:301:300:305:A1:2134:0:1036:0:prime.sky.co.nz > Prime > TV;T:602000:C0M64:C:6900:1302+1202:1402=eng:0:606:302:182:3:0:prime.sky.co.nz > > Prime TV;T:578000:C0M64:C:6900:0:0:0:0:1004:182:10:0:prime.sky.co.nz > Prime TV;T:618000:C0M64:C:6900:5041:5042:0:606:504:182:5:0:prime.sky.co.nz > Vibe;T:57:C0M64:C:6900:1304+1204:1404=eng:0:606:504:182:5:0:vibe.sky.co.nz > > > ...because my cable provider is currently transmitting prime on multiple > transponders. > (PS the Prime TV_A entry is received via a PVR-500 card) > > question - the last Prime entry and the Vibe entry have the same service > ID "504". Should my provider be using this overlap? This is probably > where my mistake was - I've now excluded the last Prime TV entry in my > xmltv2vdr processing. Using the same Sid for two different channels on the same transponder is certainly not a good idea ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems
On 22.08.2009 00:51, Simon Baxter wrote: Hi I use xmltv2vdr to process .xml EPG listings and populate VDR. VDR seems to be processing the EPG (via SVDRP) into and across two channels. There's no error in the xmltv2vdr - seems to be a VDR problem. Example: here's a snippet from "./xmltv2vdr.pl -x listings-sky.xml -c test.channels.vibe -s >>output" C C-182-5-504 Vibe;T E 8270 1250904000 3000 0 T Smallville D Clark is amazed when a pesticide magnate somehow convinces Jonathan to sell the family farm to make way for a new plant. e E 8320 1250907000 2700 0 T Smallville D When Clark rescues his classmate from harm during an electrical storm, they are both struck by lightning - resulting in all of Clark's superpowers being transferred. Lex confronts Clark about his powers. e c C C-182-2-212 Prime TV;T E 8300 1250905800 1800 0 T Chequered Flag D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. e but when I do a "LSTE at 1250905800" The "Chequered Flag" program is appearing in Prime and Vibe: 215-C C-182-5-504 Vibe 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-C C-182-10-1004 Prime TV 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-c The channel you entered EPG data for was C-182-2-212 Prime TV;T while the one listed later is C-182-10-1004 Prime TV Are you sure that this entry has not been in there for "C-182-5-504 Vibe;T" before you ran xmltv2vdr.pl? Klaus I think I've now fixed this... I did have these multiple entries in the xmltv2vdr.channels.conf file : Prime TV;T:594000:C0M64:C:6900:1312+1212:1412=eng:0:606:212:182:2:0:prime.sky.co.nz Prime TV_A:189250:C0:C:0:301:300:305:A1:2134:0:1036:0:prime.sky.co.nz Prime TV;T:602000:C0M64:C:6900:1302+1202:1402=eng:0:606:302:182:3:0:prime.sky.co.nz Prime TV;T:578000:C0M64:C:6900:0:0:0:0:1004:182:10:0:prime.sky.co.nz Prime TV;T:618000:C0M64:C:6900:5041:5042:0:606:504:182:5:0:prime.sky.co.nz Vibe;T:57:C0M64:C:6900:1304+1204:1404=eng:0:606:504:182:5:0:vibe.sky.co.nz ...because my cable provider is currently transmitting prime on multiple transponders. (PS the Prime TV_A entry is received via a PVR-500 card) question - the last Prime entry and the Vibe entry have the same service ID "504". Should my provider be using this overlap? This is probably where my mistake was - I've now excluded the last Prime TV entry in my xmltv2vdr processing. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
On Sat, 2009-08-22 at 14:31 +0300, Seppo Ingalsuo wrote: > recording.h:66: error: ‘const cEvent* cRecordingInfo::GetEvent() const’ > cannot be overloaded > recording.h:63: error: with ‘const cEvent* cRecordingInfo::GetEvent() > const’ > make: *** [channels.o] Error 1 The duplicate due to patching had to be removed from recording.h. Also there was need to include status.h to videodir.c. Now xbmc connects to vdr server and gets first radio channels, then tv channels and then nothing happens. I wonder how long it needs to be waited. Perhaps wrong/non working patches? Xmbc without vdr seems to be fine. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] gotoX patch & vdr 1.7.8
> > honestly - I don't know because the dish is on the roof of my home - I > > don't have access to it currently > > OK, that makes debugging more complicated. I connected the ampermeter for measure the current in dish cable and found out that no any problem with software - when I are moving between satellite the current is arising from 120 ma to 200-300 ma. But I don't have lock. I suppose that my dish installed not so correctly - that's why I should play with altitude and latitude. I will do. > > have you ideas about how can I see in the log the disecs commands from vdr > > to dish ? > > I don't know of logging but it should be with your diseqc.conf as simple > as: > > tone on/off > voltage 13/18 > E0 > 10 > 38 > xx > wait 150 ms > G becomes >voltage 18 >tone off >wait 20ms >EO >31 >6E >yy >zz >if repeated > wait 20 ms > E1 > 31 > 6E > yy > zz > wait dish turn for 100 ms ... 100s (e.g.) > tone on/off > voltage 13/18 > > Did you have this working with some other vdr setup or set to box? no, I have only these logs Aug 22 20:21:19 arvdr vdr: [3218] DiSEqC GotoX -192 (35008) -> -360 (35176), wait time 1.7s Aug 22 20:21:22 arvdr vdr: [3218] DiSEqC GotoX done. Aug 22 20:21:27 arvdr vdr: [3195] warning: Moving dish to 19.2E - 1s Aug 22 20:21:29 arvdr vdr: [3195] warning: Moving dish to 36.0E - 1s Aug 22 20:21:31 arvdr vdr: [3218] frontend 0 timed out while tuning to channel 13, tp 112303 Aug 22 20:21:36 arvdr vdr: [3195] switching to channel 14 Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Turn off/relocate ts error logging
On Sat, Aug 22, 2009 at 10:12 AM, Timothy D. Lenz wrote: > My log files get so big it,s very hard to check them because of the ts error > messages that get flooded to it. I've had logs near 2gb > in size. I have a problem with xine crashing when there is a weak signal and > the ts loging bloating the log files is creating a lot > of problems. Need a way to turn off ts error loging or relocate to another > file. You can use logrotate to limit the size of the log file. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Turn off/relocate ts error logging
My log files get so big it,s very hard to check them because of the ts error messages that get flooded to it. I've had logs near 2gb in size. I have a problem with xine crashing when there is a weak signal and the ts loging bloating the log files is creating a lot of problems. Need a way to turn off ts error loging or relocate to another file. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] gotoX patch & vdr 1.7.8
On Saturday 22 of August 2009, Goga777 wrote: > > have you ideas about how can I see in the log the disecs commands from vdr > to dish ? > You can add dsyslog command to each point in dvbdevice.c where this ioctl with FE_DISEQC_SEND_MASTER_CMD is called (3 times) and print out the cmd buffer. Better is to place syslog into frontend source of your card. BR, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] gotoX patch & vdr 1.7.8
On Sat, 2009-08-22 at 17:45 +0400, Goga777 wrote: > > honestly - I don't know because the dish is on the roof of my home - I don't > have access to it currently OK, that makes debugging more complicated. > have you ideas about how can I see in the log the disecs commands from vdr to > dish ? I don't know of logging but it should be with your diseqc.conf as simple as: tone on/off voltage 13/18 E0 10 38 xx wait 150 ms G becomes voltage 18 tone off wait 20ms EO 31 6E yy zz if repeated wait 20 ms E1 31 6E yy zz wait dish turn for 100 ms ... 100s (e.g.) tone on/off voltage 13/18 Did you have this working with some other vdr setup or set to box? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] gotoX patch & vdr 1.7.8
> > I have this scheme vdr with hvr4000 card ---> rotor >> 4x1 diseqc > > switch ---> LNB Ku band Linear + LNB Ku > > band Circular + LNB С band Circular > > > > my diseqc.conf (for Ku circular) is > > > > S36.0E 0 V 10750 t v [E0 10 38 F4] W150 G v t > > S36.0E 9 V 10750 t v [E0 10 38 F5] W150 G v t > > S36.0E 0 H 10750 t V [E0 10 38 F6] W150 G V t > > S36.0E 9 H 10750 t V [E0 10 38 F7] W150 G V t > > Does the dish turn? honestly - I don't know because the dish is on the roof of my home - I don't have access to it currently >I wonder if the order of G and [E0 10 38 xx] switch > command matters? > Have you enabled diseqc.conf usage from vdr lnb setup menu? yes > You could set it to no as well to eliminate diseqc.conf for a while to just > see if > the dish is moving. I suppose it should because it's not behind the > switch in your setup. have you ideas about how can I see in the log the disecs commands from vdr to dish ? Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems
On 22.08.2009 00:51, Simon Baxter wrote: > Hi > > I use xmltv2vdr to process .xml EPG listings and populate VDR. > > VDR seems to be processing the EPG (via SVDRP) into and across two > channels. There's no error in the xmltv2vdr - seems to be a VDR problem. > > Example: > here's a snippet from "./xmltv2vdr.pl -x listings-sky.xml -c > test.channels.vibe -s >>output" > > C C-182-5-504 Vibe;T > E 8270 1250904000 3000 0 > T Smallville > D Clark is amazed when a pesticide magnate somehow convinces Jonathan to > sell the family farm to make way for a new plant. > e > E 8320 1250907000 2700 0 > T Smallville > D When Clark rescues his classmate from harm during an electrical storm, > they are both struck by lightning - resulting in all of Clark's > superpowers being transferred. Lex confronts Clark about his powers. > e > c > C C-182-2-212 Prime TV;T > E 8300 1250905800 1800 0 > T Chequered Flag > D Czech Moto GP Highlights - Moto GP returns after its summer break with > the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals > Jorge Lorenzo and Casey Stoner. > e > > > but when I do a "LSTE at 1250905800" > > The "Chequered Flag" program is appearing in Prime and Vibe: > > 215-C C-182-5-504 Vibe > 215-E 8300 1250905800 1800 0 FF > 215-T Chequered Flag > 215-D Czech Moto GP Highlights - Moto GP returns after its summer break > with the Czech GP at Brno and Valentino Rossi holding a slim lead over > rivals Jorge Lorenzo and Casey Stoner. > 215-e > > > 215-C C-182-10-1004 Prime TV > 215-E 8300 1250905800 1800 0 FF > 215-T Chequered Flag > 215-D Czech Moto GP Highlights - Moto GP returns after its summer break > with the Czech GP at Brno and Valentino Rossi holding a slim lead over > rivals Jorge Lorenzo and Casey Stoner. > 215-e > 215-c The channel you entered EPG data for was C-182-2-212 Prime TV;T while the one listed later is C-182-10-1004 Prime TV Are you sure that this entry has not been in there for "C-182-5-504 Vibe;T" before you ran xmltv2vdr.pl? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
Hi, Are there cleaner or later patches somewhere for vdr (1.7.8) for xmbc? The patch vdr-1.7.4-ext68-streamdev.patch from ticket http://xbmc.org/trac/ticket/5595 could be applied but there could be some extra that I don't need from some VDR extensions patch. I'm also wondering if streamdev cvs is good as such. The HISTORY file mentions "added XBMC support by extending VTP capabilities (thanks to Alwin Esch)". Anyway this is what I got when compiling g++ -march=pentium4 -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DUSE_STREAMDEVEXTENSION -DREMOTE_KBD -DVDR_USER=\"vdr\" -DLIRC_DEVICE= \"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVIDEODIR=\"/video\" -DCONFDIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"/usr/local/share/locale\" -I/usr/include/freetype2 -I/usr/src/v4l-dvb/linux/include channels.c In file included from skins.h:17, from osdbase.h:15, from player.h:14, from status.h:15, from channels.c:17: recording.h:66: error: ‘const cEvent* cRecordingInfo::GetEvent() const’ cannot be overloaded recording.h:63: error: with ‘const cEvent* cRecordingInfo::GetEvent() const’ make: *** [channels.o] Error 1 BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] gotoX patch & vdr 1.7.8
On Sat, 2009-08-22 at 13:54 +0400, Goga777 wrote: > I have this scheme vdr with hvr4000 card ---> rotor >> 4x1 diseqc > switch ---> LNB Ku band Linear + LNB Ku > band Circular + LNB С band Circular > > my diseqc.conf (for Ku circular) is > > S36.0E 0 V 10750 t v [E0 10 38 F4] W150 G v t > S36.0E 9 V 10750 t v [E0 10 38 F5] W150 G v t > S36.0E 0 H 10750 t V [E0 10 38 F6] W150 G V t > S36.0E 9 H 10750 t V [E0 10 38 F7] W150 G V t Does the dish turn? I wonder if the order of G and [E0 10 38 xx] switch command matters? Have you enabled diseqc.conf usage from vdr lnb setup menu? You could set it to no as well to eliminate diseqc.conf for a while to just see if the dish is moving. I suppose it should because it's not behind the switch in your setup. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
2009/8/22 Thomas Hilber : > On Thu, Aug 20, 2009 at 08:31:43AM +1000, Torgeir Veimo wrote: >> In my experience, you just have to do deinterlacing in vdpau with >> interlaced content, even when displaying on an interlaced display. If >> you try to output interlaced material directly, you get ghosting since >> the weaved frames are copied to the progressive surface, and the >> output resolution might be different than the weave pattern. > > the main reason why nvidia chooses to deinterlace always even if you use an > interlaced video timing is not the scaling problem you mention. This could > be eventually solved (albeit not perfectly) by scaling both fields > independently. > > The main reason is: even with VDPAU there still exists no synchronization > between stream and video timing. I accept that they prefer "always" deinterlacing because they didn't implement proper field parity in their architecture / api / implementation. But I still think they screwed up. The matrox mga 450/550 cards do field parity pretty well, with a simple api, and in 98% of cases with predictable results and with manageable clock drift workarounds. Too bad they offer no mpeg2 or h.264 acceleration. -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
Приветствую, Vladimir > Is it AMD (ATI) have the same problem? yes. but for ati and intel there's solution from Thomas - see http://www.forum.free-x.de/wbb/index.php?page=Thread&postID=2576#post2576 http://lowbyte.de/vga-sync-fields/vga-sync-fields/ Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] gotoX patch & vdr 1.7.8
hi I tried to use the gotox patch (thanks to Seppo Ingalsuo and Ales Jurik) for vdr 178 http://www.linuxtv.org/pipermail/vdr/2009-June/020800.html I have this scheme vdr with hvr4000 card ---> rotor >> 4x1 diseqc switch ---> LNB Ku band Linear + LNB Ku band Circular + LNB С band Circular my diseqc.conf (for Ku circular) is S36.0E 0 V 10750 t v [E0 10 38 F4] W150 G v t S36.0E 9 V 10750 t v [E0 10 38 F5] W150 G v t S36.0E 0 H 10750 t V [E0 10 38 F6] W150 G V t S36.0E 9 H 10750 t V [E0 10 38 F7] W150 G V t but it seems something is wrong - I don't see anything questions - how to log the diseqc command for more investigations ? Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
On Sat, Aug 22, 2009 at 01:12:43PM +0400, Goga777 wrote: > is it possible to solve radically this problem with vdpau ? did you discuss > with nvidia developpers about this > issue ? I don't know if nvidia hardware is capable of such things at all. This issue (among others) once has been discussed somewhere here [1]. - Thomas [1] http://www.nvnews.net/vbulletin/showthread.php?t=123895 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] HD clients for vdr
Is it AMD (ATI) have the same problem? Vladimir On Sat, 2009-08-22 at 13:12 +0400, Goga777 wrote: > > the main reason why nvidia chooses to deinterlace always even if you > > use an interlaced video timing is not the scaling problem you > > mention. This could be eventually solved (albeit not perfectly) by > > scaling both fields independently. > > > > The main reason is: even with VDPAU there still exists no > > synchronization between stream and video timing. > > is it possible to solve radically this problem with vdpau ? did you > discuss with nvidia developpers about this issue ? > > Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
> the main reason why nvidia chooses to deinterlace always even if you use an > interlaced video timing is not the scaling problem you mention. This could > be eventually solved (albeit not perfectly) by scaling both fields > independently. > > The main reason is: even with VDPAU there still exists no synchronization > between stream and video timing. is it possible to solve radically this problem with vdpau ? did you discuss with nvidia developpers about this issue ? Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
On Thu, Aug 20, 2009 at 08:31:43AM +1000, Torgeir Veimo wrote: > In my experience, you just have to do deinterlacing in vdpau with > interlaced content, even when displaying on an interlaced display. If > you try to output interlaced material directly, you get ghosting since > the weaved frames are copied to the progressive surface, and the > output resolution might be different than the weave pattern. the main reason why nvidia chooses to deinterlace always even if you use an interlaced video timing is not the scaling problem you mention. This could be eventually solved (albeit not perfectly) by scaling both fields independently. The main reason is: even with VDPAU there still exists no synchronization between stream and video timing. That means there will be an arbitrary amount of lost/doubled fields with current VDPAU implementation. Nvidias workaround now is to deinterlace all content in any case. As a result these field losses are (mostly) not directly visible to the human eye. Ceasing from deinterlacing here would reveal field sequence problems (caused by missing stream-synchronization) immediately. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr