Re: [vdr] [ANNOUNCE] VDR developer version 2.1.1
Klaus Schmidinger kirjoitti 25.8.2013 kello 13.35: > - Added basic support for positioners to control steerable satellite dishes > (based on > a patch from Seppo Ingalsuo and Ales Jurik). > + Supports GotoN (aka "DiSEqC 1.2") and GotoX (aka "USALS"). > + The new DiSEqC command code 'P' can be used to instruct a positioner to > move the >dish to the required satellite position. When a 'P' code is processed, > further >execution of the remaining DiSEqC sequence (if any) is postponed until the > positioner >has reached the new satellite position. > + The new special source value of "S360E" can be used in diseqc.conf to > indicate that >an entry using a positioner can move the dish to any requested position > within its >range. Think of it as "full circle". > + The devices a particular cDiseqc or cScr applies to are now stored > directly in each >cDiseqc or cScr, respectively. > + A plugin can implement a custom positioner control (see PLUGINS.html, > section "Positioners"). > + The new function cSkinDisplayChannel::SetPositioner() can be implemented > by skins to >show the user a progress display when the dish is being moved. The default > implementation >calls SetMessage() with a string indicating the new position the dish is > being moved to. >The LCARS skin shows a progress bar indicating the movement of the dish. > + The new parameters "Site latitude", "Site longitude", "Positioner speed", > and >"Positioner swing" in the "Setup/LNB" menu can be used to configure the > necessary >values for a steerable dish. > + The cDvbTuner now has a new status tsPositioning, in which it waits until > a steerable >dish has reached its target position. Parsing SI data is paused until the > target >position has been reached. Thanks Klaus! Installed 2.1.1 today and the basics at least seem to work OK here, no unreliability (no move => messed up channels.conf) seen in operation. No more vdr patching need for me! The credits should include also Rotor plugin author (don't know his name) since the patch borrowed some code from there. Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] GOTOX patch for vdr-1.7.16
pe, 2011-01-28 kello 12:44 -0700, Timothy D. Lenz kirjoitti: > I can't try it atm because a relay went bad in my rotor. Only goes one > direction. But looking at the patch, you put the user location in the > patch, not the conf? There is an OSD menu setting for it (Settings -> LNB). The value in the patch is just some initial default. Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Remote receiver options...
On Tue, 2011-01-25 at 09:53 +, Laz wrote: > I've been following various threads over the past year or so exploring > various options for having a server-client vdr setup and it got me > thinking. > > I'm currently using a home-brew LIRC receiver attached to a serial port > which works perfectly. The ION-based boards look very nice as a vdr front > end (using xinelibout or some yet-to-be-written plugin!) because they can > do hardware HD decoding. However, I suspect a lot of these lack a serial > port so my simple LIRC receiver would be no good. My Asus ION motherboard has a serial heading in the motherboard. I'm using it for home brew serial LIRC receiver. > > What are others doing in this sort of situation? USB-based receiver (there > are a couple described at lirc.org), or do most of the ION boards still > have a serial header (must admit, not looked into this properly yet!)? I used for a while a USB-BT dongle plus PS3 Blu-Ray remote with that ION mobo. RF was pretty robust & snappy compared to IR. See http://code.google.com/p/bdremote-ng/wiki/README BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to, vdr
On Sun, 2011-01-23 at 21:38 -0700, Timothy D. Lenz wrote: > Fixed number would help a little, but would get anoying and be in the > way a lot of time. Going from one sat to the next is with in 2-3 sec's. > It's when you need to do a full swing you run into collecting from the > wrong sat. Gotox patch (thanks to Ales for years of maintenance!) tries to estimate the time for positioner turn by assuming a fixed degrees/second speed and tracking the previous position. The gotox diseqc command insertion includes the variable delay that I think is blocking vdr channel operations for this time (hope so). I made this patch because the relationship of vdr diseqc core and rotor plugin was flaky. Despite of diseqc command repetition the command success rate was well under 100%. Without repetition it was close to zero for me. My positioner may be picky with respect to signal timings. It was pretty annoying when vdr updated channels from wrong position. This patch has been reliable. The problem is that it lacks many features of rotor plugin. OTOH I think there should be a separate channel channel scan plugin. Now the most annoying thing for me is that the vdr streamdev connected 2nd and 3rd instances time out when channel switch includes long enough waiting. BR, Seppo > > On 1/23/2011 2:31 PM, Arturo Martinez wrote: > > > > :·) > > > > :·) > > > > I would also like some support for rotors in vdr, I can offer Klaus a > > free sat dish and an old rotor if that would motivate him... > > > > Klaus, as a minimum in vdr core we need the ability to specify a ´lapse > > value´ between a diseq command being sent (for non rotor users this > > would be zero, I´d imagine) and vdr tuning to a transponder or trying to > > add new channels. > > So in short if this value say was set to 30 seconds, then vdr would not > > add new channels or try to tune to a transponder. That would allow the > > rotor to do its job (with the existing diseqc.conf > > > > > > > > ___ > > 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
On 18.08.2010 11:13, jori.hamalai...@teliasonera.com wrote: I also would like to remind the framerate issues. Naturally you decide what is enough precision and quality for you. Computer hardware usually cannot provide 50.000Hz, 59.940Hz or 23.976Hz outputs to your TV/Monitor. This will cause some judder on display output as MPEG/AVC input-stream is not synchronized to output framerate. I have got "good enough" 50 Hz output to HDMI from Nvidia GS8400 DVI output with VDPAU. Typically there is small jump about every 10s with DVB SDTV content but it is visible only with graphic news scrollers. It is not annoying me that much. That is of course a very subjective matter. For example dedicated blu-ray player Philips BDP3000 had a 24.000Hz output (before firmware fix) which resulted a jumped frame every 42 seconds as real input stream is 23.976Hz. It was annoying after you noticed it. But luckily now it is fixed to real 23.976 output. With this bridge we come to VGA-hardware which might have 50.01Hz closest to 50Hz signal. So every 100 frames we get a jump in picture synch. Ever seen jumping camera panning while watching a film and got annoyed by it? Yes -- I have tried VGA but my one TV has only 60 Hz VGA mode that produces bad juddering picture. Then my other TV does not accept full HD modes via VGA. I also prefer the brighter colors and perfect pixels I get over HDMI. Subjective things again ... For ATI cards there is a dynamic framerate fix, unfortunately there is not one for Nvidia cards. Nvidia has good HW acceleration but potentially bad output. With ATI vice versa. This ATI fix fixes 50.01 by dynamically reprogramming VGA timers so real output is 50.000Hz. (General description, the author can describe more if needed). I tried two years ago a motherboard with integrated AMD graphics with HDMI but bought soon the cheap NVidia GS8400 card because of problems: poor stability/wife acceptance factor, tearing, blurry scaling etc. I am still using AMD stuff at work for desktop usage so I have seen the improvement in the open source drivers but I still feel I get better value for the money with NVidia stuff. So if you aim to HD with full HD quality I'd be carefull with computer outputs. My answer was to setup Popcorn hour to output 50.000Hz with TV-stuff. Unfortunately you lose some easy-of-use with VDR as you need to have separate layer to set up etc. I have also a PS3 and tweaked Mediatomb to serve the VDR recordings and some live TV channels over UPnP. It is slightly better with 576i50 -> 1080p50 conversion than my HTPC but the difference is quite small. I guess that is "perfect" and comparable to the picture you get with Popcorn Hour. The usability with PS3 is poor for Live TV because the channels are made to look like recordings and there is no p+ / p- channel surfing. The hack is not supporting DVB subtitles and sometimes I hear a non-prefferd sound track (the speech synth on the Dutch track). My family has learnt to use the hack while the HTPC is out of order but it is far from ideal solution. The fatty PS3 is also a bit noisy and consumes more power than a typical HTPC. I suppose the usability issues are not a problem with Popcorn if there is VDR usage dedicated firmware available? Also as original question came from Finland and if you use commercial HD channels they are (or at least should be) paired to your receiver. I see only some HD from DVB-S/S2. Fortunately the kids channels that I subscribe do not require the pairing Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
On 18.08.2010 00:36, Paul Menzel wrote: What driver did you use? I used the ppa:gma500/ppa repository as described in https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo for Ubuntu Lucid. There is lot of green in the table the real situation for this driver is not as excellent/good. Or if it is "good" then as comparison Nvidia binary driver quality is superior and high above the scale... I have had problems with Nvidia drivers but they have been solved/mitigated to usable level. Even if closed binary drivers are generally bad there are poor and usable examples. Anyway, »besides Intel Poulsbo« meant this chip is using closed drivers and is not supported by xf86-video-intel and so it does not fit into my wish list. I fully agree. If I knew this Intel chipset had only closed binary drivers I would have bought my kids another netbook. I bet there will be problems with new X.org and next Ubuntu problems. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
On Tue, 2010-08-17 at 13:39 +0300, Niko Mikkilä wrote: > Yes, as VDR User said, the latest generation VP4/VDPAU feature set C > cards (GeForce 210, GT 220, ...) have an integrated audio controller. > The ALSA driver should support 7.1 channel PCM too. > I found that someone has had success with such cards http://www.nvnews.net/vbulletin/showthread.php?t=143610&page=4 > IMO the only reason to go for a separate card over ION would be higher > quality 1080i deinterlacing. You'll need GT 220 for that since GeForce > 210 is only slightly faster than ION. They have the same video processor > and therefore the same video decoding capabilities, but post-processing > is done on the graphics cores. Good point. I think 1080i is rare content for me. If ION is as good as a GT220 with 576i, 720p and 1080p then it could be very suitable for my needs. > > > > It seems that the IONs are VP3/B so your prosal is certainly better (if > > there is HDMI audio support). > > ION2 has VP4/C, I think. > > If you don't need advanced 1080i deinterlacing, Asus AT5IONT-I is a very > good option right now. It has ION2, latest dualcore Atom and USB3, and > it's passively cooled. It's an interesting new board but I wonder if there's some risk for problems. I tried to search but I could not find reports about success with Ubuntu or Linux generally. Do Nvidia's binary graphics drivers support ION2? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
On Tue, 2010-08-17 at 13:56 +0300, Rene wrote: > I'm also starting to check for a new setup, and i'm on the same line as > you: Silent, low-power device that will runn 24/7. I have not yet looked > too much around, but there is one thing i'm wondering. What kind of > dvb-devices will you use? I use the multiple vdr instance hack proposed in xineliboutput documentation. My 2xDVB-T(dual tuners) and DVB-S2 cards are PCI and they are in a separate "home server" that runs in non-living areas of the house so noise doesn't matter. There are also several hard disks. I don't know what happens if that mobo dies. It could be difficult to find motherboards with enough legacy PCI slots. I need four because there's also one extra network card. > My current setup has two pci-cards, Full > featured Technoternd dvb-s, and an other TT budget dvb-t. I have to > replace the dvb-t card with dvb-c, because i will soon move to an area > with cable-tv.. Is it possible to go with completely dvb-usb devices? > Are thet reliable enough to not freeze/crash etc? At least for dish I need PCI type of card because USB cards do not output enough power for a motorized positioner. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
> > is there really no recommendation for a board not using Nvidia graphics > components? It would really be great to not depend on proprietary > drivers. > > The VIA chipset VX855 was supposed to have support 1080p support build > in. But those devices do not seem to be available in non Asian regions. > > AMD/ATI or Intel should also over some products fitting your need. And I > heard the drivers matured quite a bit (besides Intel Poulsbo). > > Unfortunately I do not own such systems. I installed vdr-sxfe to Poulsbo/GMA500 netbook but there is no Xv and VA API is not supported by xine-lib. There is mplayer support but I don't know if deintelacing is good. I haven't tried. An unscaled window works but fullscreen is horrible. The real Intel graphics stuff is likely better but I have no experience about that. Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
Thanks VDR User, On Sun, 2010-08-15 at 14:01 -0700, VDR User wrote: > Why not get one of the Zotac IONITX boards and stick it in the M350 > case like I did? I'm not familiar with Zotac but I could try it instead my usual of Asus mobos (the one that died was an Asus too). Zotac seems to be sold here Finland too. I'm planning to use the old Silverstone case and the old working silent high-effciency Enermax ATX power supply. That would rule out at least Asus ION deluxe style boards that seem to have an external PSU and just a DC connector in the mobo. I don't want to get external power boxes to living room and would feel sorry to throw away working stuff ;^) When considering other tips too it's going to be tough to decide what path to take here: budget/minimal vs. more power and possibly better visual quality etc. :^) > Fanless, low power, and OS can be installed on SSD, > usb flash stick, Microdrive, SD(HC), CF, you name it. They all have > usb adapters so that way your system will remain totally silent. True, my old IDE HDD is not compatible with new boards, so some flash based storage would be nice. BR, Seppo > > ___ > 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] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
Hi, Thanks Goga777, On Mon, 2010-08-16 at 00:35 +0400, Goga777 wrote: > I recommend you to use PCI-E GT220 Geforce card with motheboard which you > will choice Asus Bravo 220 silent seems to be a passive model. Do you know if these non-motherboard integrated cards support 7.1ch PCM audio over HDMI? I got as PM one tip that pointed to this page http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs I wonder if some smaller number cheaper model with similar VP4/C skills would do? E.g. Asus EN210 Silent? It could also produce less heat? The text in Wikipedia is not perfectly in line with the table so I wonder if GT2xx is needed for best VDPAU support. It seems that the IONs are VP3/B so your prosal is certainly better (if there is HDMI audio support). > > this series has very good performance for 1080i temporal_spatial > deinterlacing and h264 decoding > > have a look on qvdpautest > http://linuxdvb.org.ru/wbb/index.php?page=Thread&postID=16142#post16142 > Fortunately there's google translate - so there's some worry about passive cooled GT220s? At least the picture of Gigabyte GT220 shows a pretty large heatsink and fan ;^) BR, Seppo > ___ > 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
[vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
Hi, My old HTPC motherboard died and I'm now looking for a new one to become a vdr-sxfe "thin" client. The old Silverstone case is for normal ATX board but I no more need PCI slots so a smaller one, even a Mini-ITX would do. Since the PC runs 24/7 I'm interested in low-power motherboards with Atom CPU. There should be VDPAU support for MPEG-2 SDTV decoding + high-quality de-interlacing. I'm watching also sometimes H.264 HDTV channels from satellite. There should be 1080p50 video + up 7.1ch multi-channel PCM audio over HDMI. I'd like to get rid of SPDIF connection to AV-receiver. My HTPC box has a home-brew LIRC receiver that connected to motherboard (Asus style) COM port heading. If COM ports are history I could change to Bluetooth remote control with a PS3 Blu-Ray remote. Therefore integrated BT support would be nice (otherwise some USB-BT dongle). WLAN is not mandatory since I stream from vdr server over gigabit ethernet. Are there still issues with some ethernet chipsets and Linux? I found some options such as Asus AT3IONT-I DELUXE, Asus AT3IONT-I, Asus AT5IONT-I. I would be happy to hear experiences about these motherboards with Linux and Xine. Are there problems with some motherboard features? Other recommendations are welcome too! Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr 1.7.15 and vdradmin
On Tue, 2010-06-15 at 09:41 -0700, VDR User wrote: > On Tue, Jun 15, 2010 at 8:12 AM, Christian Wieninger > wrote: > > vdr-1.7.15 uses a new default port 6419 for SVDRP. vdradmin and epgsearch > > must be configured to the new port. > > You may also use the -p command line switch and set the port back to > 2001 if you like. That was it, thank you! BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Vdr 1.7.15 and vdradmin
Hi, Has anyone noticed problems with vdradmin-am, epgsearch and new vdr 1.7.15? Since upgrade from vdr 1.7.14 VDRadmin web interface dones not work. Web browser shows this error: "Can't connect to VDR at localhost:2001 Please check if VDR is running and if VDR's svdrphosts.conf is configured correctly." In the vdr log I see messages "EPGSearch: error connecting to socket!". My svdrphosts.conf is like with the previous version. Has something changed? Eventually I seem to loose also tuners. The log files shows e.g. "ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'". There are finnish messages "ERROR (svdrp.c,126): Liian monta avointa tiedostoa" that translates to too many open files. BR, Seppo ___ 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
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 schrieb am Fr, 5.2.2010: > > > Von: Bikalexander > > 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 : > > > 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] xineliboutput vdpau crop
On Sun, 2010-01-10 at 01:47 +0200, Mika Laitio wrote: > Hopefully this can be merged to xineliboutput repo. I wonder if it is there now in CVS? The subtitles are now scaled and in proper position but sometimes in the bottom of each row there is one pixel wide line with black and white spots. I'm using VDPAU and some HW mode for the OSD overlay on GS8400 but not HUD OSD due to tearing problems. Actually I'd prefer the unscaled 576i/p subtitles size on 1080p scaled video but on the center bottom position. The current scaled subtitles are too big and coarse at 46". Has anyone hacked the DVB subtitles like that? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
Luca Olivetti wrote: If the only planned source is a pc (running vdr and, say, xmbc), would it make sense to bypass the av receiver completely and just decode the audio on the pc connected to the speakers? Or it doesn't make sense (since you'll need an amplifier for each channel anyway, so you could just as well buy an av receiver)? Good point! I suppose the benefit of going for AVR is better speakers management: levels, delays, response correction and subwooofer crossover filters. The effects are actually usable. I'm using stereo and surround modes from Onkyo AVR. I've been also quite happy with Audussey setup. A pure PC plus amplifiers (class-D modules) could be superior to AVR in those tasks but I'm not aware of such developments for e.g. ALSA user space or PulseAudio. Just asking, since with wife, kids, and neighbours, I'll probably have to convince myself that the tv speakers are good enough ;-) The center channel is really good for any TV watching. But my wife is not happy without a properly programmed universal remote. A "watch VDR" macro does all the powering and routing. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
On Tue, 2009-11-17 at 12:28 +0200, Theunis Potgieter wrote: > In my case, I have a Samsung T260 screen with fibre out, probably > SPDIF. In this case the monitor would then be my limitation. Should I > get an amp that takes hdmi as input and passes video onto the screen? If the signal source is Blu-Ray disc then there is IMHO benefit with a HDMI capable AV receiver (excluding the early crap those were only dumb switches without audio tapping capability). Personally I've found the PCM or Dolby/DTS HD tracks sound better via possibly better mix than standard AC3 tracks. Audio coding improvement should not be that big. With just VDR DVB-C/T/S as a source there probably is no real advantage to upgrade to HDMI only over legacy SPDIF from TV to AVR setup. There could be usability improvements via CEC control channel though. And I don't know if CEC is supported by any PC HDMI hardware. (But perhaps in future VDR could get control from CEC from TV remote control too?) With my AV receiver HDMI menus it's also possible to select to route the audio to home theater or TV speakers like in your setup (with home theater system muted) though I never use TV speakers. They are pretty bad nowadays. This page might be useful http://www.hdmi.org/installers/index.aspx BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
On Sun, 2009-11-15 at 20:24 +0200, Theunis Potgieter wrote: > 2009/11/15 Timothy D. Lenz : > > The SPDIF can't carry 7.1 sound? It's just digital data stream. Should > > be able to carry how ever many channels get encoded to the data packets. > > > Is the problem not bandwidth requirements? For consumer SPDIF max bandwidth is about 2 x 20 x 48 kHz = 1.92 Mbit/s. E.g. encoded DD+ 7.1 bit stream fits there but linear 7.1 PCM doesn't. Highest end audio formats are at different order of magnitude. Dolby TrueHD can be up to 18 Mbit/s and DTS-HD Master Audio up to 24.5 Mbit/s those are passed only over HDMI in CE devices. http://en.wikipedia.org/wiki/Dolby_Digital#Dolby_Digital_Plus http://en.wikipedia.org/wiki/DTS_%28sound_system%29#DTS-HD_Master_Audio BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
On Sun, 2009-11-15 at 12:24 +0100, Artem Makhutov wrote: > Sorry, then I don't understand your problem. I have absolutly no > problems with my Zotac ION Mainboard and HDMI Audio output. I think some motherboard integrated chipsets have had working HDMI audio for some time, even Nvidia, PCI-E cards have not had the support. But I wouldn't like to swap my not-that-old P5Q motherboard for this. > I am using PCM Stereo output and when I have DD sound then I am using > AC3/DTS PassThrough over HDMI. Pass-trough (even via SPDIF) is fine if the content is DD or stereo. I suppose encoded HD audio (DTS HD or Dolby TruHD from Blu-Ray) pass-trough is missing from many graphics cards even in Windows but personally I wouldn't mind seeing 7.1ch PCM indicator instead in the AV receiver like with my fat PS3. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
On Sun, 2009-11-15 at 11:48 +0100, Artem Makhutov wrote: > You can use an .asoundrc to encode 7.1ch PCM to AC3 or DTS and use the > SPDIF over HDMI as output device. Tandem coding is not healthy for audio quality if highest quality matters and DD at handles 5.1 "only". > I am also not aware of any SPDIF cards, that can output PCM 5.1ch or > 7.1ch audio without encoding audio to AC3 or DTS manually No it's not possible because SPDIF has rather limited bandwidth. It was designed for 48 kHz 16 (up to 20) bit stereo PCM originally. The situation with Nvidia HDMI audio is perhaps improving, by Googling I found this one: http://www.nvnews.net/vbulletin/showthread.php?t=140264 Perhaps it's soon time to search for a passive cooled G210 or GT220 card! BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
On Sun, 2009-11-15 at 09:49 +0100, Luca Olivetti wrote: > Well, considering that I cannot find a way to get audio through hdmi > with my laptop and I couldn't get much help on the alsa-users mailing > list (as couldn't another folk with the same laptop 5 months ago), I am > worried. I'm waiting for a 7.1ch PCM audio over HDMI capable PCI-E graphics card. Currently Nvidia does great job with VDPAU video but SPDIF pass-trough limited audio is a disappointment. There is working 7.1ch PCM audio in Linux with AMD and Intel graphics but video acceleration is not usable. My cheap 8400GS that I bought about years ago looks still like a good solution (plus SPDIF from mobo) :^( BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe buffer empty
On Tue, 2009-10-06 at 12:01 +0930, Malcolm Caldwell wrote: > On Tue, 2009-09-29 at 17:33 +0300, Seppo Ingalsuo wrote: > > Reverse patching this one (just patch view from the same link) > > > > http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/xine_input_vdr.c?view=patch&r1=1.278&r2=1.279&sortby=date > > > > seems to work for me for current CVS version. > > What problem does this fix? > > On my setup, things run fine for a minute or so, and then audio starts > to break up more and more. It finally stops for a few seconds and then > things seem to "reset", and audio/video work fine again for a few > minutes, until the whole process starts again. > > Will reverting this fix my problem? It helped me. I had similar problems with sound. In one my PC had to in addition to use OSS (emulated sound by ALSA / PulseAudio). BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe buffer empty
Reverse patching this one (just patch view from the same link) http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/xine_input_vdr.c?view=patch&r1=1.278&r2=1.279&sortby=date seems to work for me for current CVS version. BR, Seppo On Mon, 2009-09-28 at 18:35 +0300, Seppo Ingalsuo wrote: > Shouldn't write in hurry :^) > > On Mon, 2009-09-28 at 17:18 +0300, Seppo Ingalsuo wrote: > > On Sun, 2009-09-13 at 11:08 +0400, Goga777 wrote: > > > > > please try to revert this comment > > > http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/xine_input_vdr.c?r1=1.278&r2=1.279&sortby=date > > > > > > > I was using CVS version from August 1st to avoid audio breaks. There are > > problems so I've had interest to upgrade. > > The other problem with this otherwise pretty OK version is that vdr-sxfe > stops occasionally to respond to Lirc and keyboard. Also zapping to any > HDTV channel freezes vdr-sxfe but HDTV functionality is not a big > priority for me at the moment. > > I have sampled every now and then xineliboutput CVS. E.g. Aug 24th > version has bad audio. I haven't tried to iterate where the problems > exactly started. > > > With CVS version from > > yesterday September 27th I get these problems again. > > Here I meant audio breaking problems with live TV and recordings that is > pretty annoying. > > BR, > Seppo > > > > > Would this proposed change help? The diff is rather large, do I need to > > revert everything shown by this link (or just some commment somewhere)? > > > > Is the change needed on server, client or both? > > > > Thanks, > > Seppo > > > > > > > > ___ > > 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe buffer empty
Shouldn't write in hurry :^) On Mon, 2009-09-28 at 17:18 +0300, Seppo Ingalsuo wrote: > On Sun, 2009-09-13 at 11:08 +0400, Goga777 wrote: > > > please try to revert this comment > > http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/xine_input_vdr.c?r1=1.278&r2=1.279&sortby=date > > > > I was using CVS version from August 1st to avoid audio breaks. There are > problems so I've had interest to upgrade. The other problem with this otherwise pretty OK version is that vdr-sxfe stops occasionally to respond to Lirc and keyboard. Also zapping to any HDTV channel freezes vdr-sxfe but HDTV functionality is not a big priority for me at the moment. I have sampled every now and then xineliboutput CVS. E.g. Aug 24th version has bad audio. I haven't tried to iterate where the problems exactly started. > With CVS version from > yesterday September 27th I get these problems again. Here I meant audio breaking problems with live TV and recordings that is pretty annoying. BR, Seppo > > Would this proposed change help? The diff is rather large, do I need to > revert everything shown by this link (or just some commment somewhere)? > > Is the change needed on server, client or both? > > Thanks, > Seppo > > > > ___ > 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] vdr-sxfe buffer empty
On Sun, 2009-09-13 at 11:08 +0400, Goga777 wrote: > please try to revert this comment > http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/xine_input_vdr.c?r1=1.278&r2=1.279&sortby=date > I was using CVS version from August 1st to avoid audio breaks. There are problems so I've had interest to upgrade. With CVS version from yesterday September 27th I get these problems again. Would this proposed change help? The diff is rather large, do I need to revert everything shown by this link (or just some commment somewhere)? Is the change needed on server, client or both? Thanks, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Sun, 2009-09-06 at 13:21 +0300, Lauri Tischler wrote: > I should have said 'needing X to run HD-VDR is stupid".. > I sure wish there was a NEXUS-FF-S2 card with HDMI 1080p output, > or similar, I dont like X and GUIs in general. > In old Byte Magazine guy named Steve Ciarcia said "the best compiler > is solder", still true. You should be able to get a VDPAU capable VDR front-end running without compiling yourself code. E.g. in Ubuntu Jaunty there is VDPAU capable X11 driver (plus development files). Then add from some extra repository to get xine-vdpau and vdr-sxfe. It's also easy to set up X to go up without login or without any Gnome or KDE environment of window manager. Just one vdr-sxfe window as full screen and there you are. I expect other graphics chipsets are also getting there in the future like AMD and Intel. I'm myself compiling from source and prefer to use other applications as well. As an example Google Earth as 46" full-HD is stunning for couch traveling. BR, Seppo ___ 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 Sun, 2009-08-30 at 08:49 +0300, Harri Kaimio wrote: > Hi, > > adding line > > Recordings.Sort(); > > after > > Recordings.Update( true ); > > in cConnectionVTP::CmdPLAY (in server/connectionVTP.c) fixes this > particular problem. So the problem seems to be that streamdev reloads > the recording list every now and then and does not sort it always. Thanks. That makes it work for me so that correct recording is opened. But vdr-xbmc looks rather broken othervise related to recordings. Most of the time with new videos I get only sound chirps without video. Old vdr format videos seem to work better. > > By looking at code there seems to be a similar problem when deleting > recordings which is of course even more worrying as it can lead to data > loss... I haven't verified this yet though (and cannot test it before my > kidslet me use the system again :-) Sounds scary! > > I still don't have any idea why the subtitles are not shown correctly in > recordings. Also with some recordings from Yle's TV channels XBMC plays > the wrong soundtrack (plain VDR works OK with them) I was able to open one recording from YLE Teema where subtitles were shown. It was an edited recording that seems to work better (audio chirps & no video problem). BR, Seppo ___ 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 Wed, 2009-08-26 at 22:02 +0300, Harri Kaimio wrote: > > I have the same problem with my vdr+xbmc setup. It might be a sorting > order problem: if I select nth recording from the list in XBMC (which is > in alphabetical order), vdr seems to do a depth first search in the > video directory tree without any sorting at all and plays the recording > that is in nth position in this order. Do you have idea where the error is, is it in streamdev/server/recplayer.c in function scan()? Or at upper level in connectionVTP.c? While looking the code I don't get where the bug could be. I really wonder how xbmc can be usable for some, is the separate patch for an old streamdev better? > > Also subtitles do not work for me when watching recordings (in live TV > they are OK) I haven't yet been able to randomly hit a suitable YLE recording to check that :^) BR, Seppo ___ 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 Wed, 2009-08-26 at 21:10 +0200, Magnus Hörlin wrote: > Well, it seems you're right. I've read a post somewhere that > parentalrating was needed but it seems to work just fine without it. It seems to give at least nice color coding to EPG. It's not correctly used in Finnish DVB broadcast (Mythbusters listed as sports :^) but useful any way. > And > the streamdev extensions only seem to add some messages when new > recordings start and that kind of things. Oh, that sounds important. Och tack så mycket för patch, it applied cleanly. BR, Seppo ___ 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 Mon, 2009-08-24 at 18:00 +0200, Magnus Hörlin wrote: > Hi, I've stripped the ext72 patch to contain just the two necessary > extensions streamdevext and parentalrating > and adapted it to vdr-1.7.9 but it should work for 1.7.8 also. Seems to > work here so far and it's compatible with the iptv and ttxtsubs patches. > Now all you need to get vdr-xbmc running is: > vdr (duh!) > my attatched patch for vdr > streamdevoutput plugin from cvs > XBMC pvr-testing from svn > (with the streamdev patch in the XBMC tree, the osdteletext plugin also > works) > > No guarantees that it's gonna work for you though. Thanks! I'll give it a try! Meanwhile I ran xbmc without patched vdr 1.7.9, just cvs streamdev. The functionality was quite okay with working channel selections, epg, list of recordings. Recording playback didn't work. According to vdr logs streamdev tried to start some wrong recording. I wonder if parental rating is really mandatory. On the other hand I suppose it doesn't harm. BR, Seppo ___ 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 Mon, 2009-08-24 at 09:12 +1000, Torgeir Veimo wrote: > > Maybe a streamosd plugin could provide what you need. > I can't find further information about that with Google. Is that an existing project? So, I'm not really having problem with VDR's OSD. I just want three independent user interfaces to each HTPC/television. Xbmc test drive status: I found the VDR recordings as well from xbmc but unfortunately the recordings database seems to be corrupted. Selecting something from the list brings up a random recording :^) I was just lost with UI philopsophy that is totally different from native VDR. I suppose XBMC's was developed by Microsoft so it can't be bad, it just takes some time to learn ;^) BR, Seppo ___ 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 Sun, 2009-08-23 at 09:05 -0700, VDR User wrote: > Did you know that Klaus is giving VDR a new 24bit OSD? High > resolution/high color will soon be in vanilla VDR, no expensive eHD > card or otherwise required. ;) That's nice but my main problem with vdr is having two televisions + one computer that can be used for TV watching too. HD UI is not the main driver for me. There really should be a proper server/client(s) architecture with vdr. Possible HD UI development for vdr to be useful should be developed to operate as IP streaming client. Xbmc plus vdr as video streaming source & recorder seems to be a step into that direction. It could become a great option for vdr in the future. BR, Seppo ___ 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 22:43 +0300, Seppo Ingalsuo wrote: > Now xbmc connects to vdr server and gets first radio channels, then tv > channels and then nothing happens. Now after PC and xbmc restart live tv works. Even DVB subtitles are shown! How should I access vdr recordings from xbmc? Should I somehow import vdr directory (NFS share) to xbmc video library? I'm also wondering when vdr channnels and particularly EPG are updated. Is it only when xbmc is restarted? Now I don't see EPG for satellite channels that provide only now & next or very short some hours EPG. Othervise xbmc-vdr looks very promising with totally new high definition UI. BR, Seppo ___ 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
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] 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] xbmc-pvr (was - HD clients for vdr)
Magnus Hörlin wrote: Of course it has limitations, it's a very young project. But it's progressing very fast and I think, given some time, that I will eventually abandon xinelib. At the moment I just press a button on my remote to switch between xbmc and vdr-sxfe so I can have the best of both worlds. Can a single vdr server have multiple independent xbmc clients? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD output - your current favourites
Luca Olivetti wrote: Again, I cannot tell about hdmi (though I think I'd get similar results), but on my laptop screen sd content is upscaled acceptably by xine-vdpau (the scaling and deinterlacing is done in hardware with vdpau). Horizontally scrolling text is not very good IMO. Is the laptop LCD refreshed at 60 Hz? I never got smooth TV motion on a 20" Viewsonic computer monitor. It supports all refresh rates up to 75 Hz but the visual output looked always the same as in 60 Hz mode. Televisions have native 50 Hz support so the result is better. I have now a full-HD TV as 32" computer monitor / bedroom TV. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Subtitling descriptor in ts recordings
Mikko Tuumanen wrote: Hello. VLC 1.0 doesn't even try to show subtitles from ts recordings, because vdr sets subtitling type to zero in remux.c Could it be also the reason another vdr instance that is sharing the recording directory is not able to show subtitles of recordings made with other vdr? Or it is just me and it is working for others? (I didn't yet try the patch) BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe cvs version segfault with vdr 1.7.8
Seppo Ingalsuo wrote: > > In my system CVS versions from July 22 to 23 hang up when a VDR > recording is skipped or seeked forward or backward. CVS version downloaded today works. Thanks! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe cvs version segfault with vdr 1.7.8
Petri Hintukainen wrote: > This should be fixed in CVS now. In my system CVS versions from July 22 to 23 hang up when a VDR recording is skipped or seeked forward or backward. LIve TV works. CVS version from July 18 works for me. I'm using VDPAU with up-to-date Ubuntu Jaunty. The stuck UI can be recovered by double clicking mouse for full screen vs. window mode but not via LIRC remote. Best Regards, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] bitstreamout plugin for vdr 1.7.8
Goga777 wrote: > I can listen mono and stereo audio through spdif and can't listen anything if > I switch on DD audio tarck > > Does DD pass-trough work with mplayer? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] bitstreamout plugin for vdr 1.7.8
Goga777 wrote: > is it need to use bitstreamout plugin > http://downloads.sourceforge.net/sourceforge/bitstreamout/vdr-bitstreamout-0.89b.tar.bz2?use_mirror=sunet > > for vdr 178 and vdr-xine 093 ? > Xine-lib handles encoded formats such as AC3 and DTS over S/PDIF. No vdr plugins are required. Try to set up AC3 audio from DVD first with gxine or other xine UI player. There is a pass-trough option somewhere. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] yaepghd-plugin
Jouni Karvo wrote: > > ... now I just need to find a way to open the recording dialog in > yaepghd. This one is not trivial. > > That seems to be still the problem in the current git version. It's not usable as replacement for vanilla vdr's epg. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Subtitles problem with shared vdr recordings
Hi, I have a multi-user setup as described in http://phivdr.dyndns.org/vdr/vdr-xineliboutput/ With vdr 1.7.x the DVB subtitles work only in the main vdr. In secondary vdr instances they are missing from streamed live TV and from recordings. The lack of streamed subtitles with development sofware is quite obvious because of large changes in the system. But why aren't subtitles working in the recordings. Isn't everything required to decode the subtitles included into ?.ts, index, and info files? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
Pasi Kärkkäinen wrote: > Nice. > How's the deinterlacing quality? > The 576i movement is smoother (not frame rate but the lowpass effect) than with GreedyH/GreedyL deinterlacers I used with software decoding. Greedy deinterlacers did show show jaggies sometimes so I'd say it's generally better. My viewing size for VDPAU are 46" and 32". Projector users may prefer a sharper picture perhaps? I haven't tried 1080i stuff so I can't comment that. The only problem with deinterlacing is that paused picture in vdr sometimes looks like not deinterlaced. There could be comb effect in entire screen or perhaps just one line. My graphics cards are GS8400. I wonder if there are different deinterlacers around in different nvidia generations? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
Pasi Kärkkäinen wrote: > So you have 576i 50Hz interlaced video playing at 50fps de-interlaced? > Yes, the output is 1080p50. Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
Luca Olivetti kirjoitti: > OTOH with my setup it works poorly (artifacts, banding, freezing, > changes in color, etc.) and I'm not the only one, so I'm not sure vdpau > support is mature enough for inclusion in xine-lib. > Here VDPAU works close to perfectly with two different (Intel E8200, AMD 4850E + GeForce 8400) Ubuntu Jaunty boxes with included restricted Nvidia driver and self compiled VDPAU enabled xine-lib. I had picture tearing that was solved by disabling composite extension. I lost possibility for HUD OSD for now. I needed to force also 50 Hz video mode to HDMI with custom xorg.conf modeline. Somehow probably due to extremely low CPU load VDPAU also solved breaking SPDIF sound that I had on my Asus P5Q motherboard (with similar setup the AMD780G mobo never had sound problems). 576i video scaling and de-interlacing is good quality in VDPAU. There are not many FTA HDTV channels but SDTV on Finnish DVB-T and European DVB-S works great! Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to change channels.conf externally into a running vdr?
No problem :^) I did use epgsync plugin some years ago but improvements in streamdev made it not necessary for me. Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to change channels.conf externally into a running vdr?
Gerald Dachs wrote: >> I'm now killing my secondary vdr instances while the channels are copied >> by a cron job every night. It would be more practical for remote >> vdr-sxfe clients to keep vdr processes running to avoid loosing the >> streaming connection. Is it possible to signal somehow vdr to reread >> it's entire channels.conf when it has been changed externally? By SVDRP? >> > > It sounds as if you are looking for the epgsync plugin. I do get EPG trough streamdev but some other things are broken > You can find it > here http://vdr.schmirler.de/. > It says "Imports the EPG of an other VDR. It is implemented as a separate thread and you can select either a quick but resource consuming or a slow operation mode. The later allows you to share the SVDRP connection with other local plugins, so you can e.g. still use the remoteosd plugin while syncing. Since epgsync-0.0.3 it is possible to limit the import to a specific channel type (DVB-C/S/T, analog) and to lookup channels by name instead of ID. You could e.g. copy the EPG of DVB channels to their analog counterparts." Does it synchronize channels too? BR, Seppo > Gerald > > > ___ > 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
[vdr] How to change channels.conf externally into a running vdr?
Hi, In a setup with multiple vdr instances sharing the same dvb tuners it's practical to keep one as a master that upgrades channels.conf automatically and the other instances get periodically a new copy of the channels configuration. That allows manual editing of channels in the master vdr and running plugins like autosort there. I'm now killing my secondary vdr instances while the channels are copied by a cron job every night. It would be more practical for remote vdr-sxfe clients to keep vdr processes running to avoid loosing the streaming connection. Is it possible to signal somehow vdr to reread it's entire channels.conf when it has been changed externally? By SVDRP? Seppo PS. It would be nice if multiple displays with shared server related architecture improvements were on Klaus' hidden roadmap ;^) At the moment when running several vdrs there is a mess with channels synchronization, live tv pausing, live & recording dvb subtitles, generally problems due to pay-tv watching (CAID as zero) by preventing allowing pid updates on secondary clients, etc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
Lauri Tischler wrote: > Some info about EDID > www.quantumdata.com/pdf/EDID.pps The information looks useful, thanks! > Phoenix EDID Designer 1.3 > http://www.tucows.com/preview/329441#MoreInfo > After figuring out the right hex format I tried it but I think it operates only with the standard DVI EDID not the CEA extension. Based on my partial hand decoding I think the stuff I need to edit is in the CEA extension. Or by intentionally loosing some features such as HDMI audio that I may use in the future I could of course make a 720p50 basic EDID block from scratch with this tool. BR, Seppo > ___ > 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] Best practices for running vdr-xine
Artem Makhutov wrote: > I am not sure about this. Have you tried to force a differnet resolution with > a modline? > I'm doing that at the moment but I lost the feature of making slightly underscanned desktop to compensate the overscan of this old HD Ready TV. I'm able to get a smaller resolution but it's shifted towards upper left corner and I'm not sure if vertical and horizontal shift is possible without loosing sync. Xvidtune refused to alter the mode parameters. With an old nvidia driver that scaled to closest back-end resolution (visible in nvidia-settings utility) in EDID I could this way make a centered non-scaled underscanned desktop that fitted about exactly the 1366x768 display. But now this scaling happens compared to EDID resolution that is reported as native (1080i60 I think) and the trick doesn't work. The result is a stamp sized flickering picture :^( Nvidia didn't respond at their forum. BR, Seppo > Regards, Artem > > ___ > 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] Best practices for running vdr-xine
Off-topic question: Are there any (free) EDID binary data editors available that are able to edit the CEA block http://en.wikipedia.org/wiki/EDID#Extension_Block_Details ? I'd like to disable 1080i modes from my EDID via CustomEDID option to avoid Nvidia drivers to use them as back-end resolution for scaling all modes on my HD-Ready LCD TV. 720p modes give best visual result but latest Nvidia driver's artificial intelligence decides that 1080i is best for me :^( I'm too lazy to decode, encode and compute checksum for the block by hand :^) BR, Seppo Artem Makhutov wrote: > Adding the "CustomEDID" "DFP-0:/etc/X11/LG-edid.bin" option solved everything > for me. > Now the X-Server starts with the native LCD-TV resolution, even when the TV > is turned off. > > Regards, Artem > > ___ > 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] Best practices for running vdr-xine
scott wrote: > > How did you get the smooth scrolling, mine is jerky? With latest nvidia drivers I had to disable EDID entirely to avoid getting always 1080p60 backend resolution for all modes. Here's my xorg.conf suitable for a full-HD Sony. Some smarter ways to do this would be nice. With my HTPC without AV receiver where I listen sound from TV speakers I disabled EDID because there seems to be HDMI audio support in my GS8400 card but no way to feed audio from ALSA there! Sonys select HDMI audio if it is present as even as zero stream. The benefit with this is that TV does not need to be powered when X comes up to get a valid display mode. --- # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type "man xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "Device" Identifier"Configured Video Device" Driver "nvidia" EndSection Section "Monitor" Identifier"Configured Monitor" DisplaySize 480270 ModeLine "1920x1080p50" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +HSync +VSync ModeLine "1920x1080p60" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +HSync +VSync ModeLine "1920x1080p24" 74.16 1920 2558 2602 2750 1080 1084 1089 1125 +HSync +VSync EndSection Section "Screen" Identifier"Default Screen" Monitor"Configured Monitor" Device"Configured Video Device" DefaultDepth24 Option "ExactModeTimingsDVI" "True" Option "UseEdid" "FALSE" Option "ModeValidation" "AllowNon60HzDFPModes, NoEdidModes, NoEdidDFPMaxSizeCheck, NoVertRefreshCheck, NoHorizSyncCheck, NoMaxSizeCheck, NoDFPNativeResolutionCheck" Option "UseEvents" "True" SubSection "Display" Depth 24 Modes "1920x1080p50" "1920x1080p60" "1920x1080p24" EndSubSection EndSection Section "Extensions" Option "Composite" "Enable" EndSection --- BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
Jan Ekholm wrote: > > So xineliboutput can't be what budget card people use, so I guess it's time > to > test vdr-xine. My initial gut feeling is that VDR isn't meant for X11 output > at all, and it just happens to be possible to kludge it somehow. > > Bad luck? Obsolete xine libraries? I'm running three vdr-sxfe clients at home with nice 50 Hz progressive 720p/1080p output to DVI with close to perfect vertical blanking sync (or in other words the horizontal text scrolls are smooth and sharp). I didn't get that working with on-board AMD780G graphics in my newest PC but a cheapo Nvidia card fixed that. Now I'm looking forward to eventually switch to VDPAU. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] rotor plugin, anybody got it working with vdr 1.7.5?
Hi, Does your positioner support gotox? See the patches for vdr 1.6.0 and 1.7.0 maintained by Ales J. Works for me with fine with vdr 1.7.5. There no patch rejects. http://www.linuxtv.org/pipermail/vdr/2008-September/017637.html Vdr rotor plugin stopped working for me reliably enough with multiproto drivers and probably the same issues are in s2api as well. There were timing hazards that violated the diseqc spec. This patch is based on Rotor plugin's internals patched into vdr's diseqc core. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.4 & xineliboutput
Does streamdev work with vdr 1.7.4? It's needed to make multiple vdr and vdr-sxfe instances that share the save DVB tuners. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
Jukka Vaisanen wrote: > HDMI uses DVI signalling for the video (and audio is hidden in a > vertical blanking time slot believe it or not) so it may seem like just > another connector.. however in their finite wisdom the HDMI > standardization people decided that HDMI will not support arbitrary > resolutions, but instead only the existing (and back then, planned) > broadcast resolutions: > HDMI interface does not limit the resolutions (TMDS link max. speed of course does but is another matter). It's mostly the "HD Ready" and "Full HD" television implementations that support only CEA-861-D modes for HDTV. Nothing would prevent HDTVs to introduce other modes in EDID and EDID extension blocks similarly as DVI computer monitors do. Though the timings would need be defined in such way that there is space for audio. Fortunately full HD televisions typically support 1:1 pixels over HDMI so the limited amount of modes is not that bad. GFX cards will scale other resolutions such as 800x600 and 1024x768 VESA modes into the native panel resolution. My 2c: I'm watching also a HD ready television from 2005 and despite of 2x scaling the difference with DVB PAL content is minimal to my other full HD television with only one scaling operation. The quality of the SDTV DVB-T/S content is IMHO the bottleneck instead of video scalers. Also non 1:1 pixels Gnome desktop is usable. Of course 1 pixel wide too small fonts must be avoided. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
Frank Schmirler wrote: > On Sat, 13 Dec 2008 18:52:52 +0200, Seppo Ingalsuo wrote > >> - The biggest annoyance: Possible to pause live TV only in vdr #1 >> > > Have you tried with the VDR patch from remotetimers-0.1.0? I never took the > time to test it with timersync-plugin, but I'd be interested to see if instant > recordings and pause live TV works with it, too. > I didn't know about the patch. It would be nice to get pause to work! I wonder if it solves the problems when the channels are not perfectly in sync? I have a manually sorted DVB-T channels section but my autosort handled huge amount of DVB-S channels are usually bit different in vdr instances due to frequent updates. I think timersync works only when the channel numbers match. Seppo > Cheers, > Frank > > > ___ > 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] VDR with S2API (update)
Clemens Kirchgatterer wrote: > > vdr in a massive client server configuration is a giant hack with many > pieces each with its own little problems summing up. > Not giant system, but some experiences: I have one server running three instances of vdr. Vdr #2 and #3 are connected by streamdev to vdr #1 that owns dvb hardware. Timersync plugin syncronizes timers to vdr #1. Three client PCs run just vdr-sxfe as explained in xinelibout's README file. Pros - Easy to maintain Cons - Recordings are only loosely synchronized trough a script that touches .update file when recording is started. - Deletion synchronization is not solved. - Channels are synchronized loosely by cron job only every night when clients #2 and #3 can be killed "safely" - The biggest annoyance: Possible to pause live TV only in vdr #1 I would be really happy to see improvement in vdr client-server architecture. AFAIK Mythtv does this nicely. I just have been too lazy to set up a totally new system while the current one is actively used. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + gotoXX (USALS) (was - HVR4000)
Ales Jurik wrote: > So, the goal of this patch is possible to read at > http://www.linuxtv.org/pipermail/vdr/2008-March/016164.html. > > The diseqc.conf should be like Seppo wrote in his file > http://www.linuxtv.org/pipermail/vdr/attachments/20080315/ae33847e/attachment-0001.txt. > > @Klaus: Could you please consider including this core DiSEqC/USALS feature to vdr 1.7.x development. Best Regards, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
Lauri Tischler wrote: > Hi. What card are you using to get DVB-S2 ? > Technotrend S2-3200. > CPU power ? Dual-core ? GHz ? > Intel E8200 is a low power dual core 2.66GHz chip. On arte HD (720p50) the load for vdr-sxfe (vdr server on other PC) is about 50%. > I have now AMD X2 4600 and DVB-T YLE HD is a bit jerky, sometimes, > playing recordings from YLE HD is totally jerky. > Wondering if getting quad-core 2.6GHz would help any. > Quad core could be good for 1080i stuff based on my 1st experiences ... My dual core handles 1080p24 trailers but I suppose not the better 1080p formats (and the 1080i case without going for low end deinterlacer such as bob). BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
Pasi Kärkkäinen wrote: > > Actually interlaced video kinda makes sense for sports and other live > video.. you get 50 fields per second, so the movement is smooth.. > 720p50 or even 720p60 would give superior motion with in practise better vertical resolution than 1080i. It would better to let the video encoder lose data in a controlled way than rudely alternating between two 540 line fields with interlaced video. Also now when carbon footprint matters it's insane to double every set top box / HDTV power consumption at recipient side for doing magical motion vectors based tricks in trying to restore the 1080 line image. > If you look at interlaced video on a progressive display, then you need to do > pretty > heavy deinterlacing, preferrably using "full motion" methods to get 50 or > 100 fps output.. takes a lot of CPU. Check http://www.100fps.com > > Where did you get that stream from btw? > Recorded from Anixe HD yesterday. > Digita is broadcasting this channel as 720p in DVB-T.. dunno if it's 25 fps > or 50 fps.. > Hopefully not 25 fps.. > > In what format is that Arte HD? > At the moment VIDEO: [H264] 1280x720 0bpp 50.000 fps0.0 kbps ( 0.0 kbyte/s) == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == == Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) == AO: [oss] 48000Hz 2ch s16le (2 bytes per sample) But that was an old B/W film so not real HD content. BR, Seppo > -- Pasi > > ___ > 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] OT: Finnish Yle HD olympics channel..
Pasi Kärkkäinen wrote: > Maybe try with recent mplayer (from svn).. and give it > "-demuxer lavf -lavdopts fast:threads=2 -no-correct-pts" or something > similar.. > you can also try with threads=4 etc.. > "mplayer -demuxer lavf -lavdopts fast:threads=4 -nocorrect-pts ..." gives steady but slow motion (roughly 50% speed) video. It is weird that the load on CPU1 and CPU2 is less than 40% during playback according to gnome system monitor. Somehow mplayer is not able to max both CPUs close to 100%. With mplayer I noticed that the video is 1080i -- it is silly to broadcast interlaced crap. That probably explains why vdr xinelibout choked due to greedy de-interlacer that is pretty power consuming for 1080i. Other channels such as Arte HD (arte HD;ZDFvision:11362:hC23M5O0S1:S19.2E:22000:6210:6221=deu,6222=fra:6230:0:11120:1:1011:0) work OK. BR, Seppo > -- Pasi > > ___ > 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] OT: Finnish Yle HD olympics channel..
Pasi Kärkkäinen wrote: > Unfortunately I don't have Elisa/Saunalahti ADSL.. :( > In DVB-S2 19.2E FTA channel Anixe HD there seems to be some olympics going on. ANIXE HD;BetaDigital:11915:hC910M2O0S1:S19.2E:27500:1535:1539=deu:0:0:132:0:0:0 > So, if someone is able to record/dump that stream, please do so :) > I just recorded some horse riding to try with various xine lib versions. Send me pm if you'd like to get a clip. My first try on Ubuntu 8.04 produced "[h264 @ 0x7faf7a9c7330]PAFF interlacing is not implemented gxine has suffered a fatal internal error." Xine-lib 1.2 from mercurial decodes it now but the playback is very jerky on Intel E8200 CPU. The result is not much better than on my other old AMD Sempron 3100+ based HTPC. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiproto compile fails again
Lauri Tischler wrote: > Thanks, that cured that problem, up pops next problem > --- >CC [M] /usr/src/multiproto/v4l/ivtv-i2c.o > /usr/src/multiproto/v4l/ivtv-i2c.c: In function 'ivtv_i2c_register': > /usr/src/multiproto/v4l/ivtv-i2c.c:171: error: 'struct i2c_board_info' > has no member named 'driver_name' > make[3]: *** [/usr/src/multiproto/v4l/ivtv-i2c.o] Error 1 > make[2]: *** [_module_/usr/src/multiproto/v4l] Error 2 > make[2]: Leaving directory `/usr/src/linux-headers-2.6.26-1-686' > make[1]: *** [default] Error 2 > make[1]: Leaving directory `/usr/src/multiproto/v4l' > make: *** [all] Error 2 > lassehome:/usr/src/multiproto# > I think I just removed the offending code line... :^) I'dont need it since I use only TT budget DVB cards. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiproto compile fails again
Hi,
Lauri Tischler wrote:
> /usr/src/multiproto/v4l/cx25840-core.c:71: error: conflicting type
> qualifiers for 'addr_data'
> /usr/src/multiproto/v4l/../linux/include/media/v4l2-i2c-drv-legacy.h:41:
> error: previous declaration of 'addr_data' was here
>
Please try this found from linux-dvb ml:
---
Now I found a little patch which brought me over this compile error:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/fix-jdelvare-i2c-i2c-constify-client-address-data.patch
From: Andrew Morton <[EMAIL PROTECTED]>
drivers/media/video/tvaudio.c:147: error: conflicting type qualifiers
for 'addr_data' include/media/v4l2-i2c-drv-legacy.h:37: error: previous
declaration of 'addr_data' was here Cc: Jean Delvare
<[EMAIL PROTECTED]> Signed-off-by: Andrew Morton
<[EMAIL PROTECTED]> --- include/media/v4l2-i2c-drv-legacy.h | 2
+- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN
include/media/v4l2-i2c-drv-legacy.h~fix-jdelvare-i2c-i2c-constify-client-address-data
include/media/v4l2-i2c-drv-legacy.h ---
a/include/media/v4l2-i2c-drv-legacy.h~fix-jdelvare-i2c-i2c-constify-client-address-data
+++ a/include/media/v4l2-i2c-drv-legacy.h @@ -34,7 +34,7 @@ struct
v4l2_i2c_driver_data { }; static struct v4l2_i2c_driver_data
v4l2_i2c_data; -static struct i2c_client_address_data addr_data; +static
const struct i2c_client_address_data addr_data; static struct i2c_driver
v4l2_i2c_driver_legacy; static char v4l2_i2c_drv_name_legacy[32]; Now
I'm a step further. Thanks Philipp
-- The more I learn about people, the more I like my dog!
---
BR,
Seppo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Rotor patches
My patch that patches Rotor plugin's gotox/usals functionality into vdr's DiSEqC system is here. The motivation for this work is unreliability of Rotor plugin that I experienced with multiproto driver for TT-budget S2-3200. http://linuxtv.org/pipermail/vdr/2008-March/016164.html Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
Here is something about my HTPC setup, hopefully gives some help or food for thought to set up your system [EMAIL PROTECTED] wrote: > To go back to the subject, gdm and kdm allow you to autologon an > user. The next step would be to run vdr from .xsession for ex. > For gdm, add these lines to gdm.conf to login vdr automatically AutomaticLoginEnable=true AutomaticLogin=vdr I'm using vdr (sxfe frontend from xinelibout plugin, xine plugin can be used identically) from Matchbox window manager. It provides user experience kind between set top box and normal Linux desktop. All applications are full-screen and all wm operations are possible from keyboard that can be mapped to be controlled from lirc with irxevent. In addition to vdr it's nice to run e.g. Google Earth for couch traveling or Gcompris for kids. Those require a RF keyboard/mouse joystick for controls. I had to choose once in manual login for vdr from gdm login menu other desktop than Gnome/KDE. Successive logins use this setting. ~vdr/.xsession: --- #!/bin/sh exec matchbox-session --- ~vdr/.matchbox/session: --- #! /bin/sh ## Nvidia settings #/usr/bin/nvidia-settings -l ## Start Matchbox RANDOM_IMAGE=`ls /usr/local/share/Backgrounds/*1080*jpg | rl -c 1` matchbox-desktop --icon-size 128 --icon-padding 64 --bg $RANDOM_IMAGE & /etc/init.d/irxevent.sh restart exec matchbox-window-manager -theme expose --- The Menu structure is defined in ~vdr/.matchbox/vfolders. I have created custom menus to avoid all debian stuff to show up. It is quite easy generate open desktop configuration files by hand. Top level menu is defined with these two files. Root.directory: --- [Desktop Entry] Name=Programs Name[fi]=Ohjelmat Comment=Programs menu Comment[fi]=Ohjelmat-valikko Icon=htpc-folder.png Type=Directory Match=HTPCRoot --- Root.Order: HTPC-main HTPC-internet HTPC-games HTPC-system --- Desktop icon to launch sxfe is on the top level of matchbox-desktop (/usr/share/applications/htpc-vdr-sxfe.desktop) --- [Desktop Entry] Name=VDR (Sxfe Xv) Comment=Watch digital TV, or play films and songs Exec=/usr/local/bin/htpc-vdr-sxfe.sh Icon=vdr-logo.png Type=Application Categories=HTPCMain,HTPCRoot --- /usr/local/bin/htpc-vdr-sxfe.sh --- #!/bin/sh NOW=`date "+%Y%m%d_%H%M%S"` ## Stop irxevent /etc/init.d/irxevent.sh stop ## Run vdr-sxfe /usr/local/bin/vdr-sxfe xvdr://localhost --lirc --audio alsa --video xv --fullscreen --nokbd > $HOME/vdr-sxfe-$NOW.txt ## Restart irxevent /etc/init.d/irxevent.sh start --- BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deinterlace / Motion Compensation
Boguslaw Juza wrote: > Hi! > >I have a quesion to LCD TV owners. Most of the new LCD TVs have > a "motion compensation" feature. Is it deinterlacing the picture? > I'm going to buy Sony40", to connect to PC via DVI/HDMI with 720p > or 1080p and run VDR with vdr-xine. Now Im using nvidia xxmc and > the deinterlace is ugly. With LCD TV it'll be visible much more, > so I need better deinterlacing - so I'm wondering if TV hw motion > compensation will do it... > TVs de-interlace would matter with interlaced output but I suppose field/frame accurate scaled and original way interlaced e.g. 1080i output is not possible with Nvidia and X.org. I'm using progressive 1080p50 output for 576i50 DVB-T/S video. Libxine handles de-interlacing, and Xv driver in Xorg the scaling with graphics hardware. The magic spell from xinelibout config is xineliboutput.Video.DeinterlaceOptions = method=Greedy,cheap_mode=0,pulldown=none,framerate_mode=full,judder_correction=0, use_progressive_frame_flag=1,chroma_filter=1,enabled=1 The result is IMHO pretty good with a 50 Hz X.org mode where syncronization to vertical refresh is usually close to perfect. De-interlacing consumes more CPU than 576i MPEG-2 video decoding. Advertised techniques for frame rate interpolation to 100/120 Hz perhaps matter more for typical Blu-Ray low rate 24p videos than 50/60p progressive video from PC. I haven't seen those in action so I'm only guessing. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Autosort plugin segmentation fault
Seppo Ingalsuo wrote: > #0 0xb7c2036a in free () from /lib/i686/cmov/libc.so.6 > #1 0xb74fceb1 in cMenuTimeStamps (this=0xb22f72dc) at autosort_menu.c:217 > I wonder if commenting out free() from that function is the right solution? At least timestamp menu from autosort plugin setup doesn't crash any more ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Autosort plugin segmentation fault
Hi, Anyone using autosort? I recently updated autosort 0.0.10 to 0.1.3 because 0.0.10 could not handle large sorting jobs without getting interrupted by some kind of watchdog/timeout and vdr restart (even with -w 0). With 0.1.3 I get this about once per hour. Core was generated by `vdr -c/etc/vdr -E/etc/vdr -v/opt/vdr -L/usr/local/lib/vdr -Pxineliboutput --loc'. Program terminated with signal 11, Segmentation fault. #0 0xb7c2036a in free () from /lib/i686/cmov/libc.so.6 (gdb) where #0 0xb7c2036a in free () from /lib/i686/cmov/libc.so.6 #1 0xb74fceb1 in cMenuTimeStamps (this=0xb22f72dc) at autosort_menu.c:217 #2 0xb74fae5d in cAutoSortMainThread::LoopChannels (this=0x8aee1e0) at autosort_main_thread.c:274 #3 0xb74fb08a in cAutoSortMainThread::Action (this=0x8aee1e0) at autosort_main_thread.c:61 #4 0x0811ad8c in cThread::StartThread (Thread=0x8aee1e0) at thread.c:255 #5 0xb7ecd4fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #6 0xb7c8793e in clone () from /lib/i686/cmov/libc.so.6 I found a patch from Debian for the configuration directory problem. Are there patches for this? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] newest chipset AMD 780G for home-cinema
Igor wrote: > I think it's good platform for VDR with hdtv future :) > It looks promising, I'm myself looking for H.264 HDTV decoding capable micro-ATX motherboard and wondering if there are alternatives for Nvidia's working but closed binary stuff where e.g. HDMI audio support won't be available in Linux according to nvidia's comments in their forum. Do the current x.org development drivers for AMD GPUs provide smooth SDTV and HDTV playback into DVI/HDMI with xine based software decoding with a powerful enough CPU (e.g. 45W rated Athlon 64 X2 4850E)? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
Hello, I didn't get rotor plugin to work possibly due to a tone on hazard situation compared to idle time requirements around DiSEqC message. Here is patch for multiproto/H.264 patched vdr-1.5.16 that integrates a subset of rotor plugin functions (using rotor plugin source code ;^) into vdr's LNB setup menu and DiSEqC system. It adds G command into diseqc.conf or automatically sends gotox, if gotox enabled in setup, when diseq.conf is not used before tuning. Rotor plugin is not needed. This seems to work for me. Cheers, Seppo # DiSEqC configuration for VDR # # Format: # # satellite slof polarization lof command... # # satellite: one of the 'S' codes defined in sources.conf # slof: switch frequency of LNB; the first entry with # an slof greater than the actual transponder # frequency will be used # polarization: V = vertical, H = horizontal # lof:the local oscillator frequency to subtract from # the actual transponder frequency # command: # t tone off # T tone on # v voltage low (13V) # V voltage high (18V) # A mini A # B mini B # G GotoX, includes tV W15, Gotox, W15, <2nd Gotox>, dish move wait # Wnn wait nn milliseconds (nn may be any positive integer number) # [xx ...] hex code sequence (max. 6) # # The 'command...' part is optional. # S7.0W 11700 V 9750 G v t S7.0W 9 V 10600 G v T S7.0W 11700 H 9750 G V t S7.0W 9 H 10600 G V T S5.0W 11700 V 9750 G v t S5.0W 9 V 10600 G v T S5.0W 11700 H 9750 G V t S5.0W 9 H 10600 G V T S1.0W 11700 V 9750 G v t S1.0W 9 V 10600 G v T S1.0W 11700 H 9750 G V t S1.0W 9 H 10600 G V T S5.0E 11700 V 9750 G v t S5.0E 9 V 10600 G v T S5.0E 11700 H 9750 G V t S5.0E 9 H 10600 G V T S7.0E 11700 V 9750 G v t S7.0E 9 V 10600 G v T S7.0E 11700 H 9750 G V t S7.0E 9 H 10600 G V T S10.0E 11700 V 9750 G v t S10.0E 9 V 10600 G v T S10.0E 11700 H 9750 G V t S10.0E 9 H 10600 G V T S13.0E 11700 V 9750 G v t S13.0E 9 V 10600 G v T S13.0E 11700 H 9750 G V t S13.0E 9 H 10600 G V T S16.0E 11700 V 9750 G v t S16.0E 9 V 10600 G v T S16.0E 11700 H 9750 G V t S16.0E 9 H 10600 G V T S19.2E 11700 V 9750 G v t S19.2E 9 V 10600 G v T S19.2E 11700 H 9750 G V t S19.2E 9 H 10600 G V T S21.5E 11700 V 9750 G v t S21.5E 9 V 10600 G v T S21.5E 11700 H 9750 G V t S21.5E 9 H 10600 G V T S23.5E 11700 V 9750 G v t S23.5E 9 V 10600 G v T S23.5E 11700 H 9750 G V t S23.5E 9 H 10600 G V T S26.0E 11700 V 9750 G v t S26.0E 9 V 10600 G v T S26.0E 11700 H 9750 G V t S26.0E 9 H 10600 G V T S28.2E 11700 V 9750 G v t S28.2E 9 V 10600 G v T S28.2E 11700 H 9750 G V t S28.2E 9 H 10600 G V T S28.5E 11700 V 9750 G v t S28.5E 9 V 10600 G v T S28.5E 11700 H 9750 G V t S28.5E 9 H 10600 G V T S30.5E 11700 V 9750 G v t S30.5E 9 V 10600 G v T S30.5E 11700 H 9750 G V t S30.5E 9 H 10600 G V T S31.3E 11700 V 9750 G v t S31.3E 9 V 10600 G v T S31.3E 11700 H 9750 G V t S31.3E 9 H 10600 G V T S36.0E 11700 V 9750 G v t S36.0E 9 V 10600 G v T S36.0E 11700 H 9750 G V t S36.0E 9 H 10600 G V T S39.0E 11700 V 9750 G v t S39.0E 9 V 10600 G v T S39.0E 11700 H 9750 G V t S39.0E 9 H 10600 G V T S40.0E 11700 V 9750 G v t S40.0E 9 V 10600 G v T S40.0E 11700 H 9750 G V t S40.0E 9 H 10600 G V T S42.0E 11700 V 9750 G v t S42.0E 9 V 10600 G v T S42.0E 11700 H 9750 G V t S42.0E 9 H 10600 G V T S45.0E 11700 V 9750 G v t S45.0E 9 V 10600 G v T S45.0E 11700 H 9750 G V t S45.0E 9 H 10600 G V T S47.0E 11700 V 9750 G v t S47.0E 9 V 10600 G v T S47.0E 11700 H 9750 G V t S47.0E 9 H 10600 G V T S48.0E 11700 V 9750 G v t S48.0E 9 V 10600 G v T S48.0E 11700 H 9750 G V t S48.0E 9 H 10600 G V T S50.0E 11700 V 9750 G v t S50.0E 9 V 10600 G v T S50.0E 11700 H 9750 G V t S50.0E 9 H 10600 G V T S53.0E 11700 V 9750 G v t S53.0E 9 V 10600 G v T S53.0E 11700 H 9750 G V t S53.0E 9 H 10600 G V T # Examples: # # Full DiSEqC sequence: # #S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t #S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T #S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t #S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T # #S21.5E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t #S21.5E 9 V 10600 t v W15 [E0 10 38 F5] W15 B W15 T #S21.5E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t #S21.5E 9 H 10600 t V W15 [E0 10 38 F7] W15 B W15 T # # Optimized for mini DiSEqC (aka toneburst): # # S19.2E 11700 V 9750 t v W15 A W15 t # S19.2E 9 V 10600 t v W15 A W15 T # S19.2E 11700 H 9750 t V W15 A W15 t # S19.2E 9 H 10600 t V W15 A W15 T # # S21.5E 11700 V 9750 t v W15 B W15 t # S21.5E 9 V 10600 t v W15 B W15 T # S21.5E 11700 H 9750 t V W15 B W15 t # S21.5E 9 H
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
Hi,
I haven't been able to make rotor plugin work with the multiproto
driver. I created dummy channel entries that have tone off (f < 11700)
into beginning of each satellite position group in my channels.conf and
now zapping with rotor plugin by pressing ok and then < and > keys works
with 100% success. I have been looking at rotor plugin and didn't get
idea how switching off tone could be syncronized to tuning and
diseqc.conf sequences without possible negative influence to tuning. Or
is there a guarantee for some order of execution? I wonder if it worked
with the existing Linux kernel DVB-S driver with just good luck.
Wouldn't it be better to have in diseqc.conf possibility for this kind
of setup
S19.2E 11700 V 9750 t V W15 G W15 v t
S19.2E 9 V 10600 t V W15 G W15 v T
S19.2E 11700 H 9750 t V W15 G W15 V t
S19.2E 9 H 10600 t V W15 G W15 V T
where the continuous tone is first switched off, then LNB voltage is set
to 18V for better rotor speed and then GotoX is sent with internal
computation based on new position and geographic location, etc (to be
added to vdr setup, e.g. LNB diseqc config page). There could blind be
waiting of positioning inside G operation with estimate about rotor
speed to avoid temporary tuning to intermediate positions. Finally the
proper tone and voltage is set. This way there would be exact control
when GotoX is issued. It would be possible to enable EIT scan and
channel/multiplex updates with rotor without fear that it messes up
channels.conf. With some more thinking the "t V W15" and "W15" should
perhaps be put inside "G".
This could be done by utilizing code from rotor plugin this into dvbdevice.c
if (frontendType & (DVBFE_DELSYS_DVBS | DVBFE_DELSYS_DVBS2)) {
unsigned int frequency = channel.Frequency();
if (Setup.DiSEqC) {
cDiseqc *diseqc = Diseqcs.Get(channel.Source(),
channel.Frequency(), channel.Polarization());
if (diseqc) {
if (diseqc->Commands() && (!diseqcCommands ||
strcmp(diseqcCommands, diseqc->Commands()) != 0)) {
cDiseqc::eDiseqcActions da;
for (char *CurrentAction = NULL; (da =
diseqc->Execute(&CurrentAction)) != cDiseqc::daNone; ) {
switch (da) {
case cDiseqc::daNone: break;
case cDiseqc::daToneOff: CHECK(ioctl(fd_frontend,
FE_SET_TONE, SEC_TONE_OFF)); break;
case cDiseqc::daToneOn:CHECK(ioctl(fd_frontend,
FE_SET_TONE, SEC_TONE_ON)); break;
case cDiseqc::daVoltage13: CHECK(ioctl(fd_frontend,
FE_SET_VOLTAGE, SEC_VOLTAGE_13)); break;
case cDiseqc::daVoltage18: CHECK(ioctl(fd_frontend,
FE_SET_VOLTAGE, SEC_VOLTAGE_18)); break;
case cDiseqc::daMiniA: CHECK(ioctl(fd_frontend,
FE_DISEQC_SEND_BURST, SEC_MINI_A)); break;
case cDiseqc::daMiniB: CHECK(ioctl(fd_frontend,
FE_DISEQC_SEND_BURST, SEC_MINI_B)); break;
case cDiseqc::daGotoX: {
...
int gotoXTable[10] = { 0x00, 0x02, 0x03, 0x05, 0x06, 0x08,
0x0A, 0x0B, 0x0D, 0x0E };
int satlong = (Source & ~0xC800);
if ((Source & 0xC000) != 0x8000)
return;
if (Source & 0x0800)
satlong = satlong * (-1);
int Long=data.GotoxEW ? -data.GotoxLong : data.GotoxLong;
int Lat=data.GotoxSN ? -data.GotoxLat : data.GotoxLat;
double
azimuth=M_PI+atan(tan((satlong-Long)*M_PI/1800)/sin(Lat*M_PI/1800));
double
x=acos(cos((satlong-Long)*M_PI/1800)*cos(Lat*M_PI/1800));
double elevation=atan((cos(x)-0.1513)/sin(x));
double
SatHourangle=180+atan((-cos(elevation)*sin(azimuth))/(sin(elevation)*cos(Lat*M_PI/1800)
-cos(elevation)*sin(Lat*M_PI/1800)*cos(azimuth)))*180/M_PI;
int tmp=(int)(fabs(180-SatHourangle)*10);
tmp=(tmp/10)*0x10 + gotoXTable[ tmp % 10 ];
int p2=(tmp%0x0100);
int p1=(tmp/0x0100);
if (SatHourangle < 180)
p1 |= 0xe0;
else
p1 |= 0xd0;
DiseqcCommand(Gotox,p1,p2);
}
...
break;
But as vdr illiterate I couldn't figure how to check if the zapped
source (diseqc->source?) is a new one to avoid generating unnecessary
DiSEqC traffic and delays, and wondered to get a global variable for
storing the previous position... help!
Or does this make sense?
Cheers,
Seppo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
Ales Jurik wrote: > My result is that the problem with stucked motor appears with new multiproto > driver. When I'm using multiproto from 21.12. no problem appears at all. > I couldn't repeat that but I didn't find exactly that multiproto driver. But I noticed that zapping works reliably with between channels in different positions with LNB tone off (frequency < 11700, if I got this right...). V/H polarization didn't matter (13V or 18V LNB voltage). There should be 15 ms tone off between DiSEqC messages and continuous tone that might not happen with rotor plugin and this DVB driver. I wonder if that could be the reason? I wish the GotoX would be better integrated to vdr's DiSEqC architecture. Now it looks a bit flaky, rotor plugin seems to monitor channel switch events in status.c. I wonder if additing tone off controls around gotox transmission would have impact to tuning where tone and voltage are set? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
Reinhard Nissl wrote: > As mentioned above, you'll need an updated vdr-rotor too (see > attachment), which makes use of the new API. > > Thanks! This one compiled cleanly. > Hhm, as I do not own a positioner myself, I cannot test vdr-rotor > in practice. > OK, I got some help in linux-dvb mailing list with diseqc command unreliability. Now it looks a bit better (but not yet good enough "WAF"). Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
First, thanks for your vdr patches and all the work with xine-lib! Reinhard Nissl wrote: > the attached patch replaces the previously released but > incomplete patch for VDR-1.5.14, which was part of my recent > rotor support patches. > > You have to apply this patch after patching VDR-1.5.16 with > DVB-S2+H.264 support. > Do you get this error when compiling rotor plugin (vdr-rotor-0.1.4-vdr1.5.7.tgz)? g++-4.3 -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"rotor"' -I/home/seppo/src/dvb/multiproto-0448e5a6d8a6/linux/include -I../../..//include -I/home/seppo/src/dvb/multiproto-0448e5a6d8a6/linux/include menu.c menu.c: In member function 'virtual eOSState cMainMenuRotor::ProcessKey(eKeys)': menu.c:304: error: no matching function for call to 'cChannel::SetSatTransponderData(int, int&, char&, int&, fe_code_rate)' ../../..//include/vdr/channels.h:226: note: candidates are: bool cChannel::SetSatTransponderData(int, int, char, int, int, int, int, int) menu.c:316: error: no matching function for call to 'cChannel::SetSatTransponderData(int, int&, char&, int&, fe_code_rate)' ../../..//include/vdr/channels.h:226: note: candidates are: bool cChannel::SetSatTransponderData(int, int, char, int, int, int, int, int) menu.c: In member function 'void cMenuScan::AddChannel(int)': menu.c:429: error: no matching function for call to 'cChannel::SetPids(int, int, int [33], char [33][8], int [17], char [17][8], int)' ../../..//include/vdr/channels.h:232: note: candidates are: void cChannel::SetPids(int, int, int*, char (*)[8], int*, char (*)[8], int*, char (*)[8], int) menu.c: In member function 'void cMenuScan::SetPids(int, int, int, int*, char (*)[8], int*, char (*)[8], int)': menu.c:467: error: no matching function for call to 'cChannel::SetPids(int&, int&, int*&, char (*&)[8], int*&, char (*&)[8], int&)' ../../..//include/vdr/channels.h:232: note: candidates are: void cChannel::SetPids(int, int, int*, char (*)[8], int*, char (*)[8], int*, char (*)[8], int) make[1]: *** [menu.o] Error 1 As a brutal fix I added dummy parameters (zeros, copy language strings, etc.) for SetSatTransponderData() and SetPids() calls to get it compiled. I appreciate a real correction if such exists ;^) I'm having problems in getting my diseqc motor positioner to work with multiproto+h.264 patched vdr 1.5.16. It is at the moment very unreliable. Most of the time it just stays stuck into the old position so possibly the commands get corrupted. Is a Technotrend S2-3200 capable to control a positioner? My old budget-s Tecnotrend was very reliable in driving the same positioner. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3?
Rob Davis wrote: > I have a couple of SkyStar cards on a VDR server, running xineliboutput > on an NVidia card using a VGA cable to my HDTV. I am seeing lagging, > tearing and noticeable interlacing. > For tearing check that you have sync to Vblank enabled for Xv in nvidia-settings and include running of that in non-GUI mode into your X session startup. I wonder if that is available in xorg.conf. For nvidia remember to have Option "UseEvents" "True" in xorg.conf. I wasn't able to get good motion via 60 Hz VGA and switched to HDMI that supports 50 Hz picture. I lost native panel resolution for slightly less sharp 720p mode but the overall video quality is much better. 60 Hz VGA might be good for NTSC but not for PAL. I use for deinterlacing GreedyL deinterlacer with full frame rate (judder compensation off, chroma filter on, etc.) and the result is in my opinion good. E.g. horizontal scrolling news and stock tickers look perfect, better and sharper motion than in 2nd vdr box with old 50 Hz CRT TV and DXR3. If overscan of 720p annoys and TV doesn't support underscan it is possible to compensated HDMI desktop overscan with this kind of modeline ModeLine "1224x689p50" 74.2 1224 1720 1760 1980 689 725 730 750 +hsync +vsync Then something like 3-4% overscan can be added to xineliboutput settings to hide the trash outside picture area. I had to fiddle also with nvidia-settings resolution related scaling effects to get desired overscan compensation effect. Full HD TVs fortunately support underscan or exact scan. > Is it worth buying a DXR3 on ebay? > Not if DVI/HDMI is possible. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Output methods and WSS
Kartsa wrote: > 2. And what would be the best output method? > Any of the soft devices outputting progressive de-interlaced video via DVI/HDMI to a flat panel display! I wish there would be (easy to set up) HD OSD as well ;^) Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Configuring vdr-sxfe to use a single vdr backend for recordings/dvb cards
Petri Hintukainen wrote: > I use timersync plugin to disables recording on client VDRs. All timers > are still visible at each client and you can create/modify timers at any > client just as before. Plugin synchronizes all modifications to timers > between VDR instances and takes care that all recordings are made only > by "master" vdr. Are there solutions to similarly synchronize preferably in real time channels.conf (the satellite crap is managed by autosort plugin in my setup) and recordings listing? I'm using a slightly different setup compared to your idea where I need to regularly kill the clients and copy the channels.conf from main vdr box. Recordings list gets updated when a client restarts. These limitations are currently causing confusion in my family. Best regards, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Lightning destroyed my 4 DVB-S cards, what should I replace them with?
Carsten Koch wrote: Should I still buy a FF card at all or does xine or softdevice work just as reliably by now? I don't have a FF card but using a dxr3 in my 2nd vdr box so I have some experience about HW decoded vdr -- but If you have a flat panel TV with HDMI/DVI input, I believe all the softdevices around will provide a high quality scaled and deinterlaced progressive output via graphics card DVI output. Sound cards with SPDIF or optical Toslink will give high quality audio if you have an AV receiver. I'm using myself xinelibout in daemon mode "24/7" and use vdr-sxfe (fired from Matchbox desktop that is controlled by Lirc) to connect to VDR to provide 50Hz 720p full-screen video. MPEG Decoding (Xv) is suspended by a plugin after a timeout. Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev and subtitles and HD
Hi, Pasi Juppo wrote: Is there any plans to have subtitle support for streamdev plugin? Or is there by any chance a patch that provides it? I got dvb subtitles to work thanks to this tip (in Finnish) http://www.linuxtv.fi/viewtopic.php?t=2029&start=30&sid=29c463b7f0abe6a3c18ef54d9142cdbd Using multipid streaming and manual copying of plugins/subchannels.conf from server to client seems to do the trick! Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Jouni Karvo wrote: Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started. I wonder if this would help in xorg.conf Device section Option "UseEvents" "True" (from http://www.gossamer-threads.com/lists/mythtv/users/242086) I got this tip and it helped to my random video freeze problems with Nvidia binary driver and Xv. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput settings help.
[EMAIL PROTECTED] wrote: I think with XVMC you don't get deinterlacing, because you forward sort of mpeg data to video card, and if videocard cannot do proper deinterlacing. Starting from Nvidia 6600 there is purevideo hardware deinterlacers which work ok on Windows side. Here is a summary http://www.nvidia.com/page/purevideo_support.html For SDTV the "spatial temporal" deinterlacing is supported up from 6150 and 6200 chips. A 6600 is need for HD. Despite of rumours in the nvidia forum nothing has happened to support Linux :^( On possible direction would be investigating xv_deinterlace if that can be used. But probably not with XVMC. I have been able to activate in the past some kind of linear blend (loss of vertical resolution) and bob (some blinking) deinterlacers with xxmc. Since xine-lib CVS 1.1.3/4 and new Nvidia binary drivers I'm not able to activate deinterlacing any more. This is a bit off-thread but I guess the pain in the *** interlaced video won't be killed in near future. Has anyone been able to output with xinelibout properly scaled video to 1080i over DVI/HDMI without need to de-interlace in PC but in the display device? I need X.org and like to play games in the HTPC so fbdev is not an option for me. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings sorting
Petri Helin wrote: I have used those two together and seen the feature (which I actually like quite a bit), but not the bug. I admit there is some sense in showing recordings menu after playback finishes though it is different from vanilla vdr functionality. About the bug: I think the recording menu re-appears sometimes after interrupting playback by selecting a live-tv channel from channels menu. However I'm not able to repeat that regularly. Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings sorting
Hi, Martin Prochnow wrote: if you use my ExtRecMenu-Plugin (http://martins-kabuff.de/extrecmenu_en.html), you are able to change the type of sorting (by name or by date) for each directory individually. I tried v0.12a with my streamdev vdr client, and channel sorting looks now sane for the NFS mounted recording subdirectory but there is a problem with the recording menu that pops up annoyingly after end of recording playback and sometimes in channel switching. Is that a bug or an intentional feature? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Best video card for 1080i/p with softdevice?
CR wrote: I say if you have an AGP/PCI system, consider the nVidia MX4000. I haven't used it myself with VDR but it supports XvMC (MPEG2 decode) and it's passively cooled. How good is the hardware de-interlacer? That is unknown to me, maybe someone else can comment. It's worth to check Wikipedia about various chipset generations: http://en.wikipedia.org/wiki/Nvidia#Graphics_chipsets I have in my desktop computer a 7600GS (with a nasty small heatsink and fan), the passive cooled version (Asus, etc.) would be quite suitable for a HTPC. It has quite good 3D gaming performance as well. I wish nvidia released Linux support for MPEG-4 HW decoding for pure video chipsets (6xxx and 7xxx). How do you enable the de-interlacer seppo? In xine + vdr plugin xine --no-splash --hide-gui --fullscreen -Dtvtime:method=use_vo_driver -V xxmc -A alsa vdr:/tmp/vdr-xine/stream#demux:mpeg_pes or xine + xinelibout xine --no-splash --hide-gui --fullscreen -Dtvtime:method=use_vo_driver -V xxmc -A alsa "xvdr://127.0.0.1#nocache;demux:mpeg_block" In vdr-sxfe vdr-sxfe xvdr://192.168.1.4 --lirc --audio alsa --video xxmc --fullscreen --post tvtime:method=use_vo_driver But I have some problems with sxfe, the nvidia OSD color hack (video.device.xvmc_nvidia_color_fix:1) is not available. Also the playback is not smooth when OSD graphics is active. Perhaps the sudo+renice -18 trick from this mailing list today could help. What version of xine-lib and X.Org do you use? At the moment fresh CVS, X.org 7.0 and latest (8774) nvidia binary drivers. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best video card for 1080i/p with softdevice?
Niko Mikkila wrote: cheap ATI and NVIDIA cards are good for HD video output (esp. NVIDIA because you can get MPEG-2 acceleration working with the binary drivers). The cheapest passively cooled cards work as well for video playback on Linux as the high-end models, so don't pay over 40 euros for one. Perhaps not the cheapest one. I just upgraded FX 5200 to 6200, both passive cooled low end cards. The HW deinterlacer for progressive output (720p in my case) is much better in 6xxx and 7xxx nvidias imho. In FX 5200 it was not really usable. With interlaced mode the case would be different but there the problem with cheapest cards to get 1080i over DVI. I'm not yet 100% satisfied with HW xvmc + de-interlacing with the 6200. The load in system is very low, only some % and the system is running really cool but I get video flicker (some black lines for a fraction of second) with DVB subtitles. Also the OSD has some very small vertical judder probably due to deinterlacing. Any ideas to fix these with x.org and xine settings? Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LCDproc plugin 0.1.0 with VDR 1.4.1-1
Christian Kruft wrote: does anybody have a patch to make the lcdproc 0.1.0 plugin work with VDR 1.4.1-1 ? I've tried one from January but this patch doesn't help. While starting VDR I got this errors: Close Called Not Connected !!! After that, VDR shuts down. LCDproc is working fine, only this plugin won't work. I have the same problem, patch for vdr 1.3.38 and some Makefile fixing didn't help. VDR just quits. Did you find a solution for this? Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] anyone using Technotrend Premium S2300 (Rev 2.3) "modded"
Simon Baxter wrote: Incidentally, is anyone out there using vdr-xine with HDTV? What kind of PC/hardware are you using? Any comments on quality etc?? Some DVB-S & MPEG-2 1080i demo channels still run on Sirius 5.0E. Works quite well with xine xxmc and 720p DVI/HDMI output to a LCD TV. The problem is that the HW deinterlacer in my FX5200 card is poor quality with some jagged moving edges. High quality SW deinterlacers such as GreedyH run only in "cheap" mode in my Sempron 3100+ CPU. Anyway cheap mode quality is not that bad. My first tests with Nvidia 6200 and new HW deinterlacer look quite promising. I might also try 1080i mode with xxmc and deinterlacing in TV (5200 is not capable to 1080i trough DVI). There is also support for MPEG-4 decoding in 6xxx 7xxx series nvidia cards but unfortunately not supported in Linux. Only MPEG-2 acceleration works. I wish Klaus would upgrade some day to DVB-S2 and soft HDTV decoding :^) Cheers, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
