Re: [vdr] Fwd: GOTOX patch for 1.7.5 - rotor plugin
On Fri, 2010-02-05 at 08:47 +, Newsy Paper wrote: Why not using rotor plugin? It's working ok even with 1.7.11, but there's a bug with my s2-3200. I don't know if it's a HW or SW bug, but if I am on a High Band transponder (22khz is active) the rotor doesn't move, so I have to switch to a low band transponder first. Workround would be to disable 22khz in the plugin automatically then rotate und reactive it again (if it has been active before). But I don't know how to implement that This is why originally made the patch (thanks for rotor plugin author for lot's of useful code). I got fed up to unreliable operation and messing up of channels.conf with similar frequencies from other positions. As an example I don't need gotox command repeat any more. Even with gotox repeat I got large error probability. For a vdr plugin I could not find a way to merge the operations properly to other diseqc operations while ensuring compliance with diseqc spec. I'd separate rotor plugin to a generic channel scan plugin, that it is doing nicely. Retrieve (and store position) system of elder motors should be in the core vdr dvb-s support as well IMHO. The same timing hazard is potentially there too unless retrieve position is handwritten to diseqc.conf sequences. BR, Seppo regards Newspaperman --- Bikalexander bikalexan...@gmail.com schrieb am Fr, 5.2.2010: Von: Bikalexander bikalexan...@gmail.com Betreff: [vdr] Fwd: GOTOX patch for 1.7.5 An: vdr@linuxtv.org Datum: Freitag, 5. Februar 2010, 2:17 Thanks for the link, now I've finally got the correct version:). I am using 2 DVB cards, it can be adjusted in some way that certain device is being addressed? 2010/2/4 Ales Jurik aju...@quick.cz: On Thursday 04 of February 2010, Bikalexander wrote: Even with last patch does not do it: Which exactly version of patch did you use? What was the output of patching? Was there any rejects? Did you try to patch vanilla version of vdr? Without these basic information people could only guess what happened in your vdr. For me now it works without problem (latest patch is in http://www.linuxtv.org/pipermail/vdr/2010-January/022017.html). Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fwd: GOTOX patch for 1.7.5 - rotor plugin
En/na Seppo Ingalsuo ha escrit: This is why originally made the patch (thanks for rotor plugin author for lot's of useful code). I got fed up to unreliable operation and messing up of channels.conf with similar frequencies from other positions. Yes, unfortunately a plugin has currently no way to indicate that tuning is currently impossible because the dish is moving. In the actuator plugin I disable the auto-update of channels while the dish is moving and restore the previous setting afterwards, but that isn't 100% reliable and doesn't help with the detection of dvb subtitles (which fails when the dish moves). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Strange behavior when replaying audio-only recordings with xine / vdpau
I am using VDR 1.7.11 with xine / vdpau as output device. Replaying an audio only recording (e.g. from a radio channel) or an MP3 file (with mp3 plugin) leads to two strange things: 1.) The progress bar is always several seconds ahead - at the beginning of the recording it jumps instantly to ~20sec 2.) When pressing exit during playback the sound itself stops immediately but VDR hangs up to one minute before leaving the replay. I have no idea what the reason for this could be - does anybody of you have the same issue? -- Best Regards, Joachim. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Strange behavior when replaying audio-only recordings with xine / vdpau
Hi, Am 14.02.2010 18:52, schrieb Joachim Wilke: I am using VDR 1.7.11 with xine / vdpau as output device. Replaying an audio only recording (e.g. from a radio channel) or an MP3 file (with mp3 plugin) leads to two strange things: 1.) The progress bar is always several seconds ahead - at the beginning of the recording it jumps instantly to ~20sec 2.) When pressing exit during playback the sound itself stops immediately but VDR hangs up to one minute before leaving the replay. I have no idea what the reason for this could be - does anybody of you have the same issue? I do. I have configured 2300 audio input buffers in .xine/config. In case of vdr-xine, each input buffer gets just a single audio frame which in case of usual mpeg1 layer2 audio means 24 ms audio. I haven't check yet, at which rate VDR generates index entries in case of radio recordings, but some other debug output shows that playFrame number (i. e. the frame which is currently transfered to xine) is about 800 ahead of Current (i. e. the frame which is currently played by xine), which is derived from STC, and Current is used to draw the progress bar. If you have a look into dvbplayer.c, you'll find this line: #define PTSINDEX_ENTRIES 500 It looks like VDR stores only 500 historic frame to pts associations relative to playFrame. So when you start replaying a recording, playFrame will quickly run up to something like 800. As VDR cannot find the STC value provided by vdr-xine in it's buffer, it will stay at the beginning of it's buffer and return something like 300 for Current. I assume that 300 is related to 20 seconds. I've increased the above constant for simplicity just to 5 for testing and the issue is gone at least for audio recordings, but I haven't tested the change with mp3 plugin yet. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] H264 syncearly patch
I am in the process of moving from 1.6.0 to 1.7.12 to test the pvrinput plug with a Hauppauge-PVR-HD. With 1.6.0 and the h264-syncearly patch I got a nice picture but no audio.. With 1.7.12 I can get audio but no picture. I thought h264 support was built in already to 1.7.12, but I maybe wrong. If not, where can I find an up to date patch for this? The old 1.7.0-h264-syncearly patch doesn't seem to work cleanly.. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] H264 syncearly patch
Hi, Am 15.02.2010 00:20, schrieb Reinhard Nissl: Hi, Am 14.02.2010 23:49, schrieb Rob Davis: I am in the process of moving from 1.6.0 to 1.7.12 to test the pvrinput plug with a Hauppauge-PVR-HD. With 1.6.0 and the h264-syncearly patch I got a nice picture but no audio.. With 1.7.12 I can get audio but no picture. I thought h264 support was built in already to 1.7.12, but I maybe wrong. If not, where can I find an up to date patch for this? The old 1.7.0-h264-syncearly patch doesn't seem to work cleanly.. In 1.6.x, cVideoRepacker was responsible to detect H.264 vs. MPEG2 (cannot tell why audio doesn't work in your case). In 1.7.x, cChannel provides this information (vtype). So it looks like pvrinput doesn't provide the information or channels in a way that vtype gets set to H.264. Since I'm the one who is working on supporting the HD PVR with pvrinput: Could you point me to some documentation, what kind of information the plugin has to provide? Simultaneously I'll try to search on my own, but if somebody knows it already, it'll be quicker... regards, Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
