Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
Martin, just in case you missed it, that is obviously an issue of vdr-plugin-dvbhddevice and not core VDR, maintained by Klaus ... Cheers Frank -Ursprüngliche Nachricht- Von: vdr Im Auftrag von Martin Gansser Gesendet: Dienstag, 9. Oktober 2018 10:27 An: vdr@linuxtv.org Betreff: Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope Hello Klaus, will you provide a kernel> = 4.8 patch or will I need to contact the kernel developer for this? Martin Gesendet: Sonntag, 30. September 2018 um 11:36 Uhr Von: "Klaus Schmidinger" An: vdr@linuxtv.org Betreff: Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope On 9/28/18 8:05 PM, Jasmin J. wrote: > Hi! > > This is obsolete since Kernel 4.8: > https://www.kernel.org/doc/html/v4.8/media/uapi/dvb/audio-get-pts.html > So VDR would already have needed to be changed quite some time ago. > I guess it is time to do it now. BTW: I always thought that Linux kernel policy is not to allow userspace applications to break. Apparently this is no longer the case :-(. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr[https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr] ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Translation question en -> fr
Hi Bernard, Klaus does translate this into german word "alles", "tout" in french. Cheers Frank Von: vdr [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Bernard Jaulin Gesendet: Sonntag, 2. Juli 2017 12:15 An: VDR Mailing List Betreff: [vdr] Translation question en -> fr Hello, For a better translation, did someone can explain to me what is this msgid and the context. > msgid "full" Regards, BJA. ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 2.3.2 and Plugins
Hi there, all of Rolf Ahrenbergs Plugins should run flawless with VDR 2.3.2: - satip - iptv - skinsoppalusikka - femon Use master branch of each plugin on rofafor's github repository. If anyone is interessted in Debian/Ubuntu VDR 2.3.2 packages, may give them a try: - https://launchpad.net/~fnu/+archive/ubuntu/unstable-vdr-fnu/+packages I'm going to fill it with plugins slowly. Packages are built for system.d and vdr.conf loader. Regards fnu -Ursprüngliche Nachricht- Von: vdr [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Richard Scobie Gesendet: Donnerstag, 5. Januar 2017 21:17 An: Klaus Schmidinger's VDR Betreff: [vdr] VDR 2.3.2 and Plugins Just wanted to draw attention to this thread at vdrportal for anyone who is discouraged from trying the 2.3.x vdr due to plugins not working. <http://www.vdr-portal.de/board17-developer/board97-vdr-core/130045-produktive-problem-und-pluginl%C3%B6sungen-f%C3%BCr-vdr-2-3-2-und-h%C3%B6her> Or, for English only speakers: <https://translate.googleusercontent.com/translate_c?depth=1&hl=en&rurl=translate.google.com&sl=de&tl=en&u=http://www.vdr-portal.de/board17-developer/board97-vdr-core/130045-produktive-problem-und-pluginl%25C3%25B6sungen-f%25C3%25BCr-vdr-2-3-2-und-h%25C3%25B6her/%3Fs%3D6cf8f53d317a8e7e627d38a7d7674e400fcad608&usg=ALkJrhjGdT3TSomAcn2oslhn2UWfi8ZN7A> Klaus has very generously jumped in and updated some and more are sure to follow. Anyone wanting extra skin capabilities, I have found SkinFlatPlus to work well. https://projects.vdr-developer.org/projects/plg-skinflatplus Have been running vdr 2.3.2 + dvdhddevice, femon, dvd, dvdswitch, streamdev-server and skinflatplus without problems for a couple of weeks now. Regards, Richard ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
> Out of curiosity, whats the ballpark average bitrate of your non-sports 1080p > content? Following the European Broadcasting Union (EBU) guidelines there's no 1080p broadcast in Europe and will most propably not happen. The HD formats in Europe are 1280x720p50, 1440x1080i25 and 1920x1080i25. The majority of the european public service broadcasting institutions are using 720p50. The privat broadcasting stations are using one of the 1080i25 formats, a majority 1920x1080i25. Bitrate on the 720p50 channels is up to 16Mbit/s but rarely below 10Mbit/s. The range for the private 1080i25 channels is much wider, from real bad 8Mbit/s up to 20Mbit/s on some sports channels. Thanks to Nvidias VDPAU capabilities there's no difference watching 720p or 1080i, even 576i looks like HD. => https://tech.ebu.ch/docs/techreports/tr005.pdf Stations & industries are working on 4k broadcasting, means 3840 × 2160i/p. fnu ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
Derek, you're right it's maybe possible to stack channels somewhat, but not on the user end of the "one cable". It must be "stacked" on the other end of the "one cable" and splitted again on the user side of that cable. And here's the problem, there are VDR users out there they cannot change the hardware on the other end, either not allowed or technically not possible. See my other message for the varied reasons ... As Andreas said we need to deal here with 4 sync levels on the European Astra satellites, to cover every all channels, horizontal-high, horizontal-low, vertical-high, vertical-low. So, any multiswitch does need 4 input cables from LNB, one for each level, to deliver every channel. The Multiswitch can then be a model working along CENELEC EN50494/EN50607, SCR/CSS, what does deliver multiple user bands over one cable and than splitted on user side. fnu ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
> Are you saying people are not allowed to put a switch at the point where the > cable plugins into their dvb device? It would be no different that putting an > ethernet switch on your ethernet line. You don't need to alter anything aside > of instead of the cable going into your dvb card, it goes into your switch. > 100% internal, 100% your own hardware. Derek, your simple idea sounds fantastic, I really would like to recommend that to all these users. Well, we all would have done that already, be sure ... ;-) Unfortunately the reality is little bit more difficult, one COAX cable is not enough to cover all needs for receiving satellite signal. It's enough to power one DVB card (or two in case of device bonding), if there's proper infrastructure on the other end of the cable, delivering all needs for SAT receiption. Unlike terrestric or cable signals, you cannot just split one COAX cable for satellite signals. Each DVB-S/S2 card does need to control individualy its parameters to receive a specific transponder/channel. So it's possible to mount a splitter, but VDR must be able to control that. VDR can do exactly that with device bonding aka LNB sharing ... fnu ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
Derek, pretty simple, there are users who cannot change their SAT infrastructure easily. The reasons are varied, e.g. they are tenants and not allowed to change it by the owners, they own it and cannot change it due to the rules of commonhold association or the own it and the construction of apartment/house doesn't allow changes etc. Unlike USA, Canada, not many people own houses in Europe or are living in houses with that flexibility. You're right, to have one cable for each DVB adapter is nice to have, but is sometimes not doable. The individuals who can do, will run decent SAT infrastructure, for sure. fnu ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
Derek, they do in vdr-portal.de ... as I already do remember a bunch of users still using that function and the reasons why, so no what-if-scenarios. fnu ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
> So I take it you yourself are *not* using this feature, right? Not active anymore, but in the past for many years, just up to a couple of years ago for my development machine. Getting rid of that feature may also causing the comeback of any sort of patch, maybe causing other issue, nobody can control ... As I said just my 2 cents. Cheers Frank ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
Hi Klaus, well, you're right it's a hack, but IMHO not really an ugly one. A similar function is up today part of some premium products from Loewe or Metz, bonding two DVB-S/S2 tuners. Originally it was limited to two devices, what really can make sense. I have never seen any reason to make that bonding available almost unlimited. For me it doesn't make sense to tie more than two adapters onto same ZF level. And you're right, today seems with SCR (EN50494 & EN50607) or SAT>IP more elegant solutions available. But, it would be cool to keep it for that specific two DVB-S/S2 tuner setup, if possible. There might be people out there, having just one SAT cable in their apartment and not the possibility to change the that. They would keep their chance to run "1,5 DVB-S/S2" adapters with VDR ... Just my two cents. Happy new year 2017 to all VDR fans following that Mailingslist. Cheers Frank -Ursprüngliche Nachricht- Von: vdr [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Klaus Schmidinger Gesendet: Sonntag, 1. Januar 2017 13:29 An: VDR Mailing List Betreff: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)? Implementing "device bonding" (formerly known as "LNB sharing") has had quite an impact on VDR's dvbdevice.c, and made the code quite a bit more complex. Since this feature is really just an ugly hack, and it makes much more sense to provide each device with its own antenna cable, rather that connecting two or more devices to the same cable and having to limit them to the same polarization and frequency band, I'd very much like to remove that code from VDR's source. I would therefore like to know if there are any users who actually use this, and *really* need it. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Sat>IP-plugin: how to configure 2 DD Octopus NETs with different satellites
Hi, I remember that Rolf always does suggest to use "OctopusNet" or "minisatip" as device name. So your definition is recommended to look like this: --server=192.168.1.21|DVBS2-4|OctopusNet1;192.168.1.20|DVBS2-2,DVBT2-2|Octop usNet2 The other stuff, hmm, I don't know, as the plugin follows quite straight the SAT>IP specifications. Your add-on is maybe the point to discuss with the original author Rolf. Regards fnu -Ursprüngliche Nachricht- Von: Patrick Boettcher [mailto:patrick.boettc...@posteo.de] Gesendet: Montag, 18. Juli 2016 17:43 An: fnu Cc: 'VDR Mailing List' Betreff: Re: [vdr] Sat>IP-plugin: how to configure 2 DD Octopus NETs with different satellites Hi fnu, Thank you for your answer. On Mon, 18 Jul 2016 10:29:58 +0200 "fnu" wrote: > Dear Patrick, > > changes in "sources.conf" are IIRC only necessary if you have a DiSEqC > configuration controlled by VDR. But using a/the generic sources.conf > doesn't harm VDR operation, I guess most users do have one without > DiSEqC. That seems to be true. Before looking at the code of the satip-plugin I thought that I could limit magically the created (virtual) satipDevices to the Sources assigned to them via the diseqc.conf. > You may use a workaround by using CAID field for specific adapter: > > https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#CA_- > _Conditional_access Yeah, no, I don't like this. > But I do not now if it is possible to cover more than 4 devices and no > good idea how to tie a SAT>IP device always to the same number. As said above, I dug into the code and saw that nothing can be done with standard vdr-config-files. Neither diseqc.conf nor sources.conf can help. However, I added some code and now it works as I wanted it to work. I did this by adding a Source-member to the satipFrontend created by satipServer and in satipFrontend::Assign() I additionally check whether the requested source can be delivered by this frontend. In my environment, where I have one VDR which will use all satip-devices, this is exactly what I need. Now, how to get that correctly done? Automatic detection? I haven't seen any option on the Octopus-device that would help the satip-plugin to identify automatically the source/input when it does the discovery. So, I'd opt for the command-line-parameter-option: I'd add an additional parameter to the plugin which will assign the correct source to the satipFrontend. Which would only work if the -s-option is given. Maybe it could be even part of the -s-option.. Let's try: --server=192.168.1.21|DVBS2-4|Octo1;192.168.1.20|DVBS2-2,DVBT2-2|Octo2 becomes --server=192.168.1.21|DVBS2-4|Octo1|S19.2E,S19.2E,S19.2E,S19.2E; \ 192.168.1.20|DVBS2-2,DVBT2-2|Octo2|S28.2E,S28.2E,T,T Looks good to me. I'll try that. This will surely work, however, right now, the satip-plugin does not use the fe=-parameter the RTSP-URL for that. So even with this syntax, it won't be possible to mix different satellites on _one_ Octopus NET. Like '[..]Octo2|S28.2E,S19.2E,S28.2E,S19.2E' wouldn't work without changing the URL-creation-method. It even looked like that the URL is created before the satipFrontend is chosen. That would have to be changed. best regards, -- Patrick Boettcher ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SatIP>plugin: how to configure 2 DD Octopus NETs with different satellites
Dear Patrick, changes in "sources.conf" are IIRC only necessary if you have a DiSEqC configuration controlled by VDR. But using a/the generic sources.conf doesn't harm VDR operation, I guess most users do have one without DiSEqC. And well, "diseqc.conf" does IMHO explain by itself it's function. With SAT>IP you don't use DiSEqC and it is from my understanding not foreseen to distinguish within the SAT>IP clients configuration between different orbital positions. SAT>IP specs do cover several positions but managed by the SAT>IP server. In your case one Octopus Net mainboard holding all of your flex modules and VDR is asking for the different positions by using the different channel.conf entries. You may use a workaround by using CAID field for specific adapter: https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#CA_-_Conditional_access But I do not now if it is possible to cover more than 4 devices and no good idea how to tie a SAT>IP device always to the same number. Regards fnu -Ursprüngliche Nachricht- Von: vdr [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Patrick Boettcher Gesendet: Sonntag, 17. Juli 2016 15:36 An: VDR Mailing List Betreff: [vdr] SatIP>plugin: how to configure 2 DD Octopus NETs with different satellites Hi, I have 2 DD Octopus NET devices. One is a 2x DVB-S(2) + 2x DVB-T(2) (let's call it AA) and the other one is 4x DVB-S(2) (BB). AA's satellite orientation is Astra 28.2, BB's one is Astra 19.2. How can I associate AA's or BB's inputs in VDR's configuration so that it uses 1) the right input for the right source 2) the maximum number of devices in parallel for recording, epg-scanning etc. conf.d/50-satip.conf contains --devices=8 --server=192.168.1.21|DVBS2-4|Octo1;192.168.1.20|DVBS2-2,DVBT2-2|Octo2 I found discussions where they say that in sources.conf one needs to assigned device numbers, so I tried: S19.2E 1 Astra 1KR/1L/1M/2C S19.2E 2 Astra 1KR/1L/1M/2C S19.2E 3 Astra 1KR/1L/1M/2C S19.2E 4 Astra 1KR/1L/1M/2C S28.2E 5 Astra 1N/2A/2F S28.2E 6 Astra 1N/2A/2F This isn't working, it seems that even for S28.2 channels it selects the S19.2-devices. Then I changed the diseqc.conf to 1 2 3 4: 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 5 6: S28.2E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t S28.2E 9 V 10600 t v W15 [E0 10 38 F5] W15 B W15 T S28.2E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t S28.2E 9 H 10600 t V W15 [E0 10 38 F7] W15 B W15 T Didn't help. Is there anything I can do? Thanks in advance for any help. Best regards, -- Patrick. ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T2 device in France
Nicolas, ok, two points just for my couriousity. 1. Why don't you share channels.conf from your server as you do it with EPG data? 2. Why don't you enable EPG scan just for a few hours for the channels scan and delete epg.data afterwards again? By chance I tested the same a couple of days ago on my Octopus (DVBS-8) and it took just 20min to fill the channels.conf with ~1300 channels from Astra 19.2°E ... Regards Frank -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Nicolas Huillard Gesendet: Montag, 28. September 2015 16:40 An: VDR Mailing List Betreff: Re: [vdr] DVB-T2 device in France Le lundi 28 septembre 2015 à 12:55 +0200, fnu a écrit : > per specs channel scan is not inteded for the SAT>IP servers, this is > client's responsibility. I fully understand this point, but since the Octopus has a web interface and apparently also acts as a DLNA DMS, I think it could be a nice addition to have at least basic channel scanning, just to provide a smoother starting with the device (which is neally neat in every other aspects). > VDR doesn't provide an active channel scan option, so don't blame and > point just the plugin, which does run awesome stable here since spring > 2014. I don't "blame" anything, and I trust that plugin to work flawlessly. I still have power supply issues on the Raspberry Pi which masks all that stability ;-) As of now, this is a task for the soldering iron. > VDR does provide a passive channel scan, only caveat you need at least > one working line in channels.conf. If you have that, go to OSD / Setup > / DVB and set "Update channels:" to "add new transponders" (setup.conf > / UpdateChannels = 5). After some time of patience you should find a > properly filled channels.conf, ready to be sorted. That's what I tried, with the channel.conf I have from the VDR server, but it didn't catch newer channels, even though "some time" was a day or two. I suspect this is something related to MANUAL.gz stating "Note that adding new transponders only works if the "EPG scan" is active.", and the fact that EPG is currently meant to be shared from the VDR server, and apparently not working... Even UpdateChannels = 4 didn't add anything. I'll deal with this and bother the ML if I can't manage it ;-) > Cheers > Frank > > -Ursprüngliche Nachricht- > Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im > Auftrag von Nicolas Huillard > Gesendet: Montag, 28. September 2015 12:18 > An: VDR Mailing List > Betreff: Re: [vdr] DVB-T2 device in France > > Thanks for all your answers ! > > I finally opted for the Digital Devices Octopus Net, which DVT-T2 tuners are > equipped with Sony D2837ER demodulators, which happen to completely solve the > bad reception issue. Great ! > > Now I have a whole new set of problems : SAT>IP (with the satip plugin which > seems to be great, and channel scan which is as of now non-solved ; too bad > the Octopus couldn't channel-scan by itself and provide an initial > channel.conf or VLC playlist) and Raspberry Pi client which is a bit tricky > (power issues, media player, disappointingly weak CEC support on the TV side, > etc...). > > At least, I can upgrade the VDR server without breaking the DVB kernel > drivers, and upgrade the VDR client without breaking X.org or xinelib > ;-) > > Le lundi 21 septembre 2015 à 15:37 +0100, Stuart Morris a écrit : > > I have a 290e I use for DVB-T2 reception and it has worked really > > well for some time now. > > Shame you can't buy them anymore :-( > > > > On 19 September 2015 at 10:21, Jari Fredriksson wrote: > > > > > On 17.9.2015 15:01, Nicolas Huillard wrote: > > > > > >> Hello all, > > >> > > >> My previous mail to this ML is apparently dated 2011 ;-) > > >> Everything was OK there since then... Except that my Hauppauge > > >> Nova-T-500 died recently, and my ancient PCI cards do not work in the > > >> 2013 server. > > >> > > >> I'm looking for advice for a new DVB-T2 device, which should : > > >> * have a good tuner, because some channels (transponders, ie. > > >> frequencies) are difficult to catch here ; the TV set (Panasonic) > > >> works perfectly well, and I've added an RF amplifier on the roof, > > >> so I guess the Nova-T-500 tuner was not good enough > > >> * have a PCI or preferably PCI-e bus, and dual tuner (I don't > > >> really like USB sticks, which tend to lead to a mess of cable) > > >> * be robust
Re: [vdr] DVB-T2 device in France
Hi Nicolas, per specs channel scan is not inteded for the SAT>IP servers, this is client's responsibility. VDR doesn't provide an active channel scan option, so don't blame and point just the plugin, which does run awesome stable here since spring 2014. VDR does provide a passive channel scan, only caveat you need at least one working line in channels.conf. If you have that, go to OSD / Setup / DVB and set "Update channels:" to "add new transponders" (setup.conf / UpdateChannels = 5). After some time of patience you should find a properly filled channels.conf, ready to be sorted. Cheers Frank -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Nicolas Huillard Gesendet: Montag, 28. September 2015 12:18 An: VDR Mailing List Betreff: Re: [vdr] DVB-T2 device in France Thanks for all your answers ! I finally opted for the Digital Devices Octopus Net, which DVT-T2 tuners are equipped with Sony D2837ER demodulators, which happen to completely solve the bad reception issue. Great ! Now I have a whole new set of problems : SAT>IP (with the satip plugin which seems to be great, and channel scan which is as of now non-solved ; too bad the Octopus couldn't channel-scan by itself and provide an initial channel.conf or VLC playlist) and Raspberry Pi client which is a bit tricky (power issues, media player, disappointingly weak CEC support on the TV side, etc...). At least, I can upgrade the VDR server without breaking the DVB kernel drivers, and upgrade the VDR client without breaking X.org or xinelib ;-) Le lundi 21 septembre 2015 à 15:37 +0100, Stuart Morris a écrit : > I have a 290e I use for DVB-T2 reception and it has worked really well > for some time now. > Shame you can't buy them anymore :-( > > On 19 September 2015 at 10:21, Jari Fredriksson wrote: > > > On 17.9.2015 15:01, Nicolas Huillard wrote: > > > >> Hello all, > >> > >> My previous mail to this ML is apparently dated 2011 ;-) Everything > >> was OK there since then... Except that my Hauppauge Nova-T-500 died > >> recently, and my ancient PCI cards do not work in the 2013 server. > >> > >> I'm looking for advice for a new DVB-T2 device, which should : > >> * have a good tuner, because some channels (transponders, ie. > >> frequencies) are difficult to catch here ; the TV set (Panasonic) > >> works perfectly well, and I've added an RF amplifier on the roof, > >> so I guess the Nova-T-500 tuner was not good enough > >> * have a PCI or preferably PCI-e bus, and dual tuner (I don't > >> really like USB sticks, which tend to lead to a mess of cable) > >> * be robustly supported with stock kernels in Debian (jessie and > >> future), which does not seem to be a problem anymore... > >> > >> If there are some dual-tuner, DVB-T2 + S2 card out there which are > >> well supported by VDR, that's OK too. I may prefer to add another > >> DVB-S2 card later on though (there is no sat-dish on the roof yet). > >> > >> TIA ! > >> > > > > > > I use an USB tuner "PCTV Systems nanoStick T2 290e" from Hauppauge. > > It has a good Sony tuner, and DVB-T2 in my setup works fine even > > with an desktop antenna (the broadcast mast is in visible range though). > > > > Driver is in kernel, and this was the first Linux tuner for DVB-T2 > > and supported even in the older kernels. I use it in a Raspberry Pi > > 2 with two DVB-C tuners and I'm all happy. > > > > > > -- > > jarif.bit > > > > ___ > > 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 -- Nicolas Huillard nico...@huillard.net Fixe : +33 9 52 31 06 10 Mobile : +33 6 50 27 69 08 http://www.350.org/ ___ 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] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years of VDR!
> http://www.heise.de/newsticker/meldung/Seiner-Zeit-voraus-Klaus-Schmidingers -Video-Disk-Recorder-VDR-2552972.html Great! Thank you Tobias, Mirko Doelle and Peter Siering! === Regards Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years of VDR!
Well done mate, congrats for 15 wonderful years, what changed TV life and habbits of many people worldwide! Thanks for all of your work and passion. === Cheers Frank -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Klaus Schmidinger Gesendet: Donnerstag, 19. Februar 2015 11:39 An: vdr@linuxtv.org Betreff: [vdr] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years of VDR! VDR version 2.2.0 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.2.0.tar.bz2 A 'diff' against the previous developer version is available at ftp://ftp.tvdr.de/vdr/vdr-2.1.10-2.2.0.diff MD5 checksums: 8853f64c0fc3d41ffd3b4bfc6f0a14b7 vdr-2.2.0.tar.bz2 2d75806f90a4f1c8b3e30d7568891dc6 vdr-2.1.10-2.2.0.diff A summary of all the major changes since the last stable version 2.0.0 can be found at http://www.tvdr.de/changelog.htm When updating from an earlier version of VDR please make sure you read the INSTALL and MANUAL files that come with the VDR source _before_ doing so! Please make sure you have backup copies of all your configuration files, and verify carefully that your timers will be set to the correct channels after switching to this new version. Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR, and also to all users who have been enjoying VDR over the past 15 years! Please also visit the VDR homepage at http://www.tvdr.de and VDR's facebook page at https://www.facebook.com/VideoDiskRecorder Have fun! Klaus ___ 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] DVB-S2 PCIe or USB tuner recommendations?
Hi Stephan, search for Linux4Media/DigitalDevices CineS2 cards. Either revision V5.4/5.5 which does use kernel module "ngene", what is upstream since kernel version 3.0 (IIRC). You or your Linux distro just need to provide a proper firmware file "ngene_18.fw". I did run these cards rock solid over very long time in my VDR, but you can't get them new anymore. Alternatively you could go for revision v6.2, what does use kernel module "ddbridge", kernel upstream since version 3.2 (iirc), no firmware file needed. I do run one of these still in my main VDR using upstream kernel module, but also sometimes with additional packages like dddvb or media_build_experimental. You can get these cards still new at Linux4Media online shop. http://www.l4m-shop.de/index.php?cat=c6_L4M-Twin-Karten-PCIexpress-L4M-Twin- Karten-PCIexpress.html === Kind regards Frank -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Stephan Loescher Gesendet: Samstag, 7. Februar 2015 20:20 An: VDR Mailing List Betreff: [vdr] DVB-S2 PCIe or USB tuner recommendations? Hi! I am planning to build a new VDR system for HDTV and DVB-S2. So I am searching for DVB-S2 tuners either PCIe (low profile) or USB. The best tuner would be one which is supported by the vanilla Linux kernel without patching or installing additional drivers. (Installing a firmware file is no problem.) I have already searched http://www.linuxtv.org/wiki/, but there are only a few current tuners, which are documented as "works with vanilla kernel out of the box", e.g. Pinnacle PCTV DVB-S2 Stick (461e) or TeVii S471. (The others good working ones are not any longer available, even not as second hand.) So I am looking for your recommendations for current DVB-S2 PCIe/USB tuners, which work "out of the box" and work stable for a 7x24 running VDR. TIA and best regards, Stephan. -- loesc...@gmx.de http://www.loescher-online.de/ ___ 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 from native speakers needed: To "bisect" or to "halve"?
Hi Klaus, yes, very good ... :) === Kind regards Frank -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Klaus Schmidinger Gesendet: Freitag, 6. Februar 2015 18:22 An: vdr@linuxtv.org Betreff: Re: [vdr] Advice from native speakers needed: To "bisect" or to "halve"? Thanks for all the helpful responses. The final verdict is: Initial duration for adaptive skipping (s) = 120 Defines the number of seconds to jump from the current replay position in either direction, when pressing the '1' or '3' key for the first time after the "Reset timeout for adaptive skipping". The valid range is 10...600. Reset timeout for adaptive skipping (s) = 3 Defines the number of seconds after which pressing the '1' or '3' key falls back to the "Initial duration for adaptive skipping". The valid range is 0...10. Setting the timeout to 0 disables the adaptive mode and makes '1' and '3' always skip the number of seconds configured as the initial duration. Alternate behavior for adaptive skipping = no When skipping in adaptive mode with the '1' and '3' keys, the distance of the skip is halved with every key press after the first change of direction. While this allows for locating a particular position in a recording very fast, once you make one step too many in the current direction you have no chance of ever reaching the desired point any more. You will have to wait for the timeout to occur and start adaptive skipping anew. If this option is set to 'yes', the skip distance will only be halved if the direction actually changes. That way, even if you missed the target point, you can still back up to it. Klaus ___ 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] still image at end of replay
> You can do that already. Use the iptv plugin, create a channel that shows a static picture, Smart idea, but wife is also required to go to bed all the time ... SCNR ... ;-) === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] still image at end of replay
> This really sounds like something that should be solved in parenting and not code. I fully agree to that, as dad of now almost adult kids, espacially if it's bed time ... If these kids are so little, why do they watch TV at all w/o parental advice and why could there be a channel underneath showing something what the little ones shouldn't watch? But kids are kids, doing whatever come to their minds, they can't be controlled all times. What may be sufficient is to implement a kind of PIN control, like on commercial receivers. A function where to set a white list of channels which can be watched w/o PIN and the list is then valid for recordings, too, where the source channel is also stored. But bed time is still human responsibility ... ;-) === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] skipping 5/10 seconds
> If I officially use them for a function that is (IMHO, agreed) unnecessary, then they would be wasted for future use for functions that might be more important ;-). Well these keys are unused for 14 years now and yes, they could be saved for any usage another 14 years, ..., doing nothing ... ^^ I agree with all supporters, I like that function, and them on discrete keys. I would also not have problems to patch it further. But it's also ok to use other discrete keys, e.g. the proposed usage of right/left in replay mode, just to find a global agreement for core VDR. Maybe there's a way to make it definable for the rare cases an user doesn't have a remote with discrete fastfwd/fastrwd keys ... In the many years of using VDR I rarly used fastfwd/fastrew, since jumping a few seconds is much more comfortable and therfore important to me. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] vdr-plugin-satip 0.0.1 - Make your VDR to a SAT>IP receiver
Hi VDR followers, since the author Rolf Ahrenberg obviously isn't part of this mailing list anymore, I do the annoucement on his behalf: "This plugin integrates SAT>IP network devices seamlessly into VDR. You can use any SAT>IP channel like any other normal DVB channel for live viewing, recording, etc. The plugin also features full section filtering capabilities which allow for example EIT information to be extracted from the incoming stream." - http://www.saunalahti.fi/~rahrenbe/vdr/satip/ Download and README. Rolf Ahrenberg also does provide a new "vdr-plugin-femon" (2.0.3) to support SAT>IP devices in VDR. - http://www.saunalahti.fi/~rahrenbe/vdr/femon/ For Debian & Ubuntu aware users, I already created a DEB package/framework for further usage: - https://launchpad.net/~fnu/+archive/testing-vdr-fnu/+sourcepub/4007335/+list ing-archive-extra - https://launchpad.net/~fnu/+archive/testing-vdr-fnu/+sourcepub/4007336/+list ing-archive-extra - https://launchpad.net/~fnu/+archive/testing-vdr-fnu/+sourcepub/4007363/+list ing-archive-extra - https://launchpad.net/~fnu/+archive/testing-vdr-fnu/+sourcepub/4007362/+list ing-archive-extra Use "dget -xu ...dsc" to grab it for your own usage or repository. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-fritzbox no longer working after FBF firmware upgrade
Harald, yes, newer do version work with Fritz!OS beyond 5.5x. I'm using actually 1.5.2 with Fritz!OS 6.01. === Kind regards fnu > -Original Message- > From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf > Of Harald Milz > Sent: Tuesday, January 21, 2014 11:06 AM > To: VDR Mailing List > Subject: [vdr] vdr-fritzbox no longer working after FBF firmware upgrade > > Hi all, > > I've been happily using vdr-fritzbox for a very long time. Since the > last upgrade to Fritz!OS 5.50 and then to 5.53 (54.05.50 respectively > 54.05.53) the plugin cannot connect to the FBF any more. The log: > > Jan 21 10:10:58 seneca vdr: [2393] [libfritz++/FritzClient.cpp:210] > logging into fritz box using old scheme without SIDs. > Jan 21 10:10:59 seneca vdr: [2393] [libfritz++/FritzClient.cpp:228] > login successful. > Jan 21 10:10:59 seneca vdr: [2393] [libfritz++/FritzClient.cpp:317] > sending callList request. > Jan 21 10:11:01 seneca vdr: [2393] [libfritz++/FritzClient.cpp:342] > Exception in connection to 192.168.20.253 - Could not connect Jan 21 > 10:11:01 seneca vdr: [2393] [libfritz++/FritzClient.cpp:342] waiting > 3600 seconds before retrying > > VDR and plugin are the standard versions in Ubuntu 12.04 LTS: > > ii vdr1.7.22-1 > ii vdr-plugin-fritzbox1.4.1-4 > > didn't have an opportunity to check out later versions yet. Should that > be fixed by now? > > THX! > > > -- > Do not overtax your powers. > > ___ > 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] [ANNOUNCE] VDR developer version 2.1.3
> I will! :) Who not ... ;-) > Thanks for a bunch of little gems in this release like "obsolete > channels". Yes, indeed ... :tup > Have to dig into the new CAM stuff, maybe now it's possible to > integrate the CI of Digital Devices... That would be great, christmas has gone recently, but I wouldn't say no for delayed present. === Kind regards fnu > -Original Message- > From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf > Of Lars Hanisch > Sent: Sunday, January 05, 2014 12:54 PM > To: vdr@linuxtv.org > Subject: Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3 > > Am 05.01.2014 12:42, schrieb Klaus Schmidinger: > > VDR developer version 2.1.3 is now available at > > > > ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.3.tar.bz2 > > > > A 'diff' against the previous version is available at > > > > ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.2-2.1.3.diff > > > > MD5 checksums: > > > > 054f80e0045aa6fad118e9285b52f4f2 vdr-2.1.3.tar.bz2 > > 3c5ab05d5c4d0b984b34e84190e80949 vdr-2.1.2-2.1.3.diff > > > > WARNING: > > > > > > This is a *developer* version. Even though *I* use it in my productive > > environment, I strongly recommend that you only use it under > > controlled conditions and for testing and debugging. > > > > > > Originally I intended to release this version only after the new > > DiSEqC configuration dialog was finished. But in the meantime quite a > > few other things have come up, so I decided to postpone that dialog > > and first release what has piled up so far. > > > > > > The changes since version 2.1.2: > > > > - Changed the return value of cPositioner::HorizonLongitude() to 0 in > case the > > latitude of the antenna location is beyond +/-81 degrees. > > - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). > > - Fixed some compiler warnings with gcc-4.6.3 (thanks to Rolf > Ahrenberg). > > - Changed the name of the SVDRP command RENR to MOVR (suggested by > Rolf Ahrenberg). > > - When cutting a recording it is now checked whether there is already > an edited > > version of this recording (with the same name, but starting with > '%'), and the > > user is prompted for confirmation to overwrite it (suggested by Rolf > Ahrenberg). > > - Revoked "Added maximum signal strength value for TechniSat SkyStar 2 > DVB-S rev 2.3P" > > because it broke things for the "TechniSat AirStar 2" DVB-T card. > > - The LIRC remote control now connects to the socket even if it > doesn't yet exist when > > VDR is started (thanks to Lars Hanisch). > > - Changed the absolute latitude limit for visible satellites to 81.2 > degrees. > > - Added code for parsing LCN and AVC descriptors to libsi (thanks to > Rolf Ahrenberg). > > - In the "Select folder" menu pressing Ok now selects the folder, even > if this is a > > folder that contains sub folders (marked with "..."). To open such a > folder you > > can press the Red key. > > - Fixed a possible access to uninitialized data in cEIT::cEIT() > (reported by Dominik > > Strasser). > > - The new menu category mcRecordingEdit is now used to mark menus that > edit recording > > properties (suggested by Stefan Braun). > > - Changes in the teletext PID no longer cause retuning (and thus > interrupting a > > recording). > > - Removed '_' from the FileNameChars and CharMap translations in > uk_UA.po. > > - Updated the Italian OSD texts (thanks to Diego Pierotto). > > - Fixed a missing initialization in the c'tor of > cSkinLCARSDisplayChannel (thanks to > > Marko Mäkelä). > > - Simplified some conditional expressions in skinlcars.c and > skinsttng.c (suggested > > by Marko Mäkelä). > > - Fixed uninitialized item area coordinates in cSkinLCARSDisplayMenu > (reported by > > Marko Mäkelä). > > - Fixed a possible crash if the recordings list is updated externally > while the > > Recordings menu is open (reported by Lars Hanisch). > > - Added a missing closing ')' in the help and man page entry of the -- > vfat option > > (reported by Lars Hanisch). > > - Fixed setting the name of the video directory to avoid a crash when > using --genindex, > > and also to use the correct directory with --edit (the latter > reported by Marko > > Mäkelä). > > - The Recordings menu can now be called with a cRecordingFilter, which > allows the > > caller to have it display only a certain
Re: [vdr] Change vdr shutdown command (into pm-suspend)
Hey Cedric, looks like you are using a Debian based installation, probably with Debian packages based on Tobias Grimm's great work over years, and for sure his co-workers. Obviously you're dutch and maybe capable to understand some gernan words. So, you may have a look into an article Tobias wrote quite a while ago on his homepage: http://www.e-tobi.net/blog/2010/11/06/squeeze-vdr-teil-9-suspend-to-ram This way does work also perfectly with Ubuntu … ;-) === Kind regards fnu From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of cedric.dew...@telfort.nl Sent: Friday, December 06, 2013 6:18 PM To: VDR Mailing List Subject: [vdr] Change vdr shutdown command (into pm-suspend) Hi All, I'm trying to make my TV server faster by calling pm-suspend instead of shutdown. I have made a script that stops vdr, unloads the DVB-t driver, suspend, resume, load the DVB-t driver, and restart VDR. This works nicely., see here for details: http://forums.debian.net/viewtopic.php?f=5 <http://forums.debian.net/viewtopic.php?f=5&t=109612> &t=109612 Now I'm trying to automate it. VDR is capable of shutting down the PC. This can be setup in /etc/default/vdr Is there any way to let VDR call pm-suspend instead of /sbin/shutdown? Where is the setting for it? Best regards, Cedric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel IDs - DVB-C and IPTV
Hey Michael, glad to here that you got it work. So after using correct SID, NID and TID, still no EPG from EIT? Since you may not be the only user in Austria, using A1TV's IPTV channels, you may post the proven channel.conf entries with correct SID, NID and TID at vdr-portal.de. === Kind regards fnu > -Original Message- > From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf > Of Michael Frank > Sent: Tuesday, August 20, 2013 12:03 PM > To: VDR Mailing List > Subject: Re: [vdr] Channel IDs - DVB-C and IPTV > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > @fnu > > Thank you Frank for your kind help. Analyzing the streams was the first > step towards success. > > Finally I found the reason why RID would not work with my IPTV-Channels. > It's very simple: apparently SVDRP does not like an NID of zero. As soon > as you set it to 1 the RID can be used as well. > > The import of EPG-data from epgdata.com is now working fine for my IPTV- > Channels from a1tv. > > Thanky again > > Kind regards > Michael > > > Am 2013-08-19 17:35, schrieb fnu: > > Hey Michael, > > > > since I dealt somewhat intensiv with IPTV channels the last days, > > German T-Home Entertain, see vdr-portal, I was able to check this > quickly. > > > > DVB-S/S2: > > === > > vdr2-vdr:/home/vdr> svdrpsend lstc 1 > > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:12:24 2013; > > UTF-8 > > 250 1 Das Erste > > HD;ARD:11494:HC23M5O35S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;51 > > 06=deu > > @106:5104;5105=deu:0:10301:1:1019:0 > > 221 vdr2 closing connection > > === > > vdr2-vdr:/home/vdr> svdrpsend lstc S19.2E-1-1019-10301-0 > > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:30:30 2013; > > UTF-8 > > 250 1 Das Erste > > HD;ARD:11494:HC23M5O35S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;51 > > 06=deu > > @106:5104;5105=deu:0:10301:1:1019:0 > > 221 vdr2 closing connection > > === > > IPTV: > > === > > vdr2-vdr:/home/vdr> svdrpsend lstc 120 > > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:13:16 2013; > > UTF-8 > > 250 120 Das Erste > > HD;IPTV:110:S=0|P=0|F=UDP|U=239.35.10.1|A=1:I:0:256=27:257=deu@3;2 > > 58=AC3 > > @106:259:0:10301:1:10301:0 > > 221 vdr2 closing connection > > === > > vdr2-vdr:/home/vdr> svdrpsend lstc I-1-10301-10301-0 > > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:13:24 2013; > > UTF-8 > > 250 120 Das Erste > > HD;IPTV:110:S=0|P=0|F=UDP|U=239.35.10.1|A=1:I:0:256=27:257=deu@3;2 > > 58=AC3 > > @106:259:0:10301:1:10301:0 > > 221 vdr2 closing connection > > === > > > > So SVDRP does work proberly here. > > > > I also read this RID hint to give channels a unique touch, but I think > > it might be the better idea to find out correct SID, NID, TID for > > these channels and leave RID=0. I needed to do this, to get the few > > EPG info out of that streams. Luckily I had strong support by plugin's > > author, Rolf Ahrenberg, thanks again for that here. > > > > In short do something like this, I did show my own example from above: > > > > === > > #/> /usr/bin/multicat -u -d 162000 @23.35.10.1:1 ./dump.ts === > > Dump 1min of that stream, 81=5min, 162000=1min, > > 81000=30sek === Check the dump: > > === > > #/> dvbsnoop -s ts -if ./dump.ts -tssubdecode -hexdumpbuffer 0x12 | > > grep -m1 > > -A8 Service_ID | grep _ID > > === > > You will get something like this, that shows SID, NID and TID: > > === > > Service_ID: 10301 (0x283d) [= --> refers to PMT program_number] > > Transport_stream_ID: 10301 (0x283d) > > Original_network_ID: 1 (0x0001) [= Astra Satellite Network 19,2-E | > > Soci-t- Europ-enne des Satellites] > > === > > === > > Kind regards > > Frank > > > >> -Original Message- > >> From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On > >> Behalf Of Michael Frank > >> Sent: Monday, August 19, 2013 4:52 PM > >> To: VDR Mailing List > >> Subject: [vdr] Channel IDs - DVB-C and IPTV > >> > > Hello, > > > > I have a VDR (2.0.2) setup with yaVDR's distribution using a Sundtek > > stick to watch DVB-C. Additionally I want to add a part of a1tv > > (Austrian IPTV) to the setup. While watching IPTV does not pose any > > problems, getting the EPG into these IPTV-Channels does. > > > > a1tv does not provide EPG via the dat
Re: [vdr] Livebuffer for VDR 2.0
> I tested a 1.7.x version some long time ago, but that did not > work as well as the "original" version.. There has never ever been any official Livebuffer feature in any VDR version. I hope it'll take a long time to make it into VDR, e.g. as long as it took to get any file-/recordings-management feature or other really useful stuff into VDR ... ^^ === Kind regards Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
> Klaus is already doing people a massive favour by maintaining this Make > system and continuing to support it. FullAck, I guess most people appreciate this way, it makes live not that bad, some minor changes needed to keep any plugin. There's more work for many plugins regarding other changes in VDR, despite which Makefile system. This was IMHO a great job, to keep 99% of the old system with the view into the future. With post 2.0 Klaus can now uncompromising cut everything old and unnecessary, which will probably sort out 80% of all plugins and make distributors live even easier ... ^^ Thanks for this great work up to now Klaus! === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] 0.1.0
René, well you could go the hard way and try a mix of repository based VDR plus any self-compiled Plugins, in that case I would rather suggest to do everything by yourself inkl. VDR ... Or a little easier Debian/Ubuntu way, look here: http://goo.gl/Xz7zm, usage: "sudo apt-add-repository ppa:yavdr/testing-vdr" Our packages do base closely on Tobi's work. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] small patch for vdr.c: continue even with read-only video directory
> and it's important for me, that vdr cannot write anything to the video directory. Since this is important for you personaly, you want to change VDR for all users, are you serious? >From my personal point of view a read only video directory with an video disk recorder doesn't make much sense. But I wouldn't deny the need, because obviously there a single user out there who does need it, strange enough ... But to change it in a global way like this is IMHO not a way to go. The correct solution would be that any user needing it, must decide and configure something. So, a kind of a switch like an OSD option or even a better way, VDR does check existence of a file in this video directory, e.g. ".vdrro", something similar to ".nodelete" ... === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] osdteletext and constant disk access with 1.7.38
> Can someone confirm and/or have ideas what might be causing this and if the osdteletext plugin needs some adjustments to behave properly with new VDR versions? IMHO normal behavior ever of that plugin. Most of us just put that data onto a "RAM disk" (tmpfs), whereas teletext data is nothing what need to be saved at shutdown, it's just runtime data ... === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Call for translations for VDR version 2.0.0
> looks nice, vdrportal.de also looks nice rich and lively. unfortunatly it's in Deutsch ! :) I don't rembember who wrote it, but at vdr-wiki.de is an user manual for VDR in german language, just as an example, not more not less. Instead of fighting about the right way to translate it, save your energy for a thing like this. Each of us should be able to read and understand the others language, happy birthday Franco-German friendship ... ^^ Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Call for translations for VDR version 2.0.0
> It's definitely difficult to provide short translations of short english technical keywords and sentences. If you don't make in couple of words, why translate it? Keep it in the proper short technical english original, it's not any prose what need to be translated sensitively. In many cases it is the same with the german language ... Or try any similar meaningful short french word, also no need to translate technical stuff word by word, why? For that 2 people reading it 2 times in 3 years? If they need it, they should look for the meaning of that technical points ... Think about a little question, is there a need to translate "exit"? I know you guys do it (e.g. sortie), but I guess all of the 7 billion people on this planet do understand "exit" in it's sense, or not? So what to say, less is even more in many cases ... And to explain specific points, a manual might be better idea instead of overload VDR with any help fuction, have a look e.g at vdr-wiki.de ... Happy translating, cheers, fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> von Klaus Schmidinger > But with the recent "shitstorm" I'm having second thoughts... Hmm, I had also read shitstorms, this does have a different quality. I would also take it positiv, nobody is questioning your execellent work, in contrary, a lot of do take part of it and are interessted in. So, controversial discussions are sometimes necessary ... Who did post Linux Torvalds words as an example ... ? === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> by VDR User > but I guess your friends disagree. Not only my friends, e.g. one guy of an international customer, a US citizen living in Germany since 10-15 years, is not willing to talk in german with us. Just another example, but even our famous foreign workers from all over Europe do better here, only the french do worse ... ;-) > I hope you don't misunderstand, I wasn't complaining that vdrportal isn't english-friendly. No, no, I got it. What is the most famous english speaking forum? === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> As good as vdrportal is as a VDR resource, the language barrier _is_ a problem for english speakers. Same with this mailing list for german speakers ... and now? > or feeling like a welcome visitor/member A little tale, if I'm in the US, I have to speak english all time. If my US friends do visit me or colleagues are staying in Germany, I also have to speak english all the time. They don't even try to speak my/our language while staying in Germany. And hey, don't think they ever welcomed me in german language ... ^^ This is just a chicken-and-egg problem, you all don't try to use it, so no information is collected or any kind of community will be set up. There is an rarly used international part, but if somebody does ask in english, she/he gets an answer in english, wherever postet. Time and patience could solve a lot, even losing shyness of nativ german speakers to answer in english, but this up to you all ... Unfortunately the search function of vdr-portal sucks IMHO, so in all languages, better use google w/ "site:vdr-portal.de what-you-search-for". === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> von Vidar Tyldum > Why are the majority of the users German - and why does it stay that way? Is it for the greater benefit of VDR? This is not the fault of the german users, VDR is historically a "german speaking project", initiated by a german guy, used by the biggest VDR community, german, austrian and swiss people. I guess most of them don't feel save enough to write in english, they don't want to be blamed for not being nativ speaker and vdr-portal.de is far the better way to find information and solution. You should rather ask why the rest does not join this biggest VDR forum? There are a lot of people answering in english ... > von Christopher Reimer > Then tell me why was there no answer on the mailinglist thread. Nobody did oversea the consquences and all are surprised due to this eat and die change, obviously initiated bottomline by one person. Again it is absolutely not against the change, it might be necessary, but not now and not in this way. I'm not anymore sure that VDR is a kind of community project, where here and there are thoughts about all participants. This number here reminds me more on George Orwells Animal Farm. Let 1.7.3x become a stable branch and postpone this change to the next development cycle. So, everybody does get time to get saddled for this change but with an HDTV capable fallback. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> von Christopher Reimer > Yes, I am happy with the new makefiles. I'm glad to hear this, but what about all the other developers and users? Developer version back and forth, VDR 1.7.xx has become silently a somewhat stable version over the years, due to it's HDTV capability. Becoming an official stable is honestly long overdue. Nobody can really argue anymore, 1.7 is a developer version, because no HDTV user, not even Klaus, can go back to stable SDTV VDR 1.6, whereas the majority doesn't have any hardware for that anymore ... A massive excluding change like this, is something for a new developer branch and not a thing for a development cycle where the end could already be smelled ... And as far as I remember nobody did complain about the old Makefile structur, and yes I mean nobody, because the two now known just changed it w/o warning. Do what ever you need to do, I appriciate it, but remind always some continuity for all others in the VDR universe. The situation right now does need a solution, but it can't be the words of Walter Ulbricht: "Vorwärts immer, rückwärts nimmer ..." A compromise must be possible, whatever it looks like, otherwise my comparison with "Louis XIV" hasn't been wrong ... === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> von Klaus Schmidinger > From what I have seen in this thread lately, I don't think the outcry would have been any less then... You're maybe right, but I'm not sure. Because now, everybody does know, these changes will happen soon, no Plugin for V2.1 w/o rework. But V2.1 is near future, so time for rework, V1.7.xx is present, right now, looking for continuity. Kick a sibling of 1.7.33 out as V2 or maybe an in between stable release called V1.8 and go ahead with these important changes in V1.9 ... just a thought ... === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> von Manuel Reimer > The changes in 1.7.34 are a big change into the right direction! FullAck, but really at that time of 1.7.xx? At this time where 1.7.xx is more less saddled by all HDTV users? Many new festures have been postponed after V2 release. Some of them wouldn't have this significant impact to the VDR univers, like these changes on the Makefile structure. Wouldn't it possible to focus release of V2 and set these changes as very first change on the upcoming developer release. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> Let's not waste more mailing list space with this nonsense. I got it already, you're way of installation and usage of VDR is the only valid, all others are stupid. Your statements here are the one and only truth, even so only you are allowed to make conclusions. Yes man, you're the very last knight keeping the holy grail of VDR. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> users when there's plenty of evidence that says otherwise. You did not provide any ... you also just pray your truth ... > It may be hard for you to accept but reality is that VDR has a successful life way past yavdr and `apt-get install vdr`. Yes, I know, I have been part of it. I still keep the same historic case of the first VDR ever, bought in 2000 after my first contact to Klaus, see pic on tvdr.de ... So, fortunately the majority of Linux world has left the "make; make install" cave. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> I think fnu is wrong in his assumption that "over 95% of VDR users" I'm not wrong, the users compiling VDR from scratch are far in minority. Again I'm not just talking about ready to run ISO images. There are plenty of silent users working the packages out of Linux' distros repositories, Debian, Ubuntu, Gentoo, Fedrora etc. Many of them run VDR underneath any other HTPC solution. These users don't argue on mailing lists nor on the different forum, so nobody can hear them. On top of these amount, there are a lot of silent users running ISO based VDRs. I assume there is still a good hundred linvdr installations out there, running their good old FF cards. But that is not the topic here, it's more that the few maintainers of these repositories, what ever kind, are ignored in their needs to provide usable packages to these quite huge number of users. A few DIY users are more equal then even fewer distro and packaging maintainers ... === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Dominic, good one! I know, a coin has always two sides, but hack, look where Linux nowadays is . ^^ Cheers Frank Im Auftrag von Dominic Evans Gesendet: Freitag, 28. Dezember 2012 00:47 An: VDR Mailing List Betreff: Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35 On 27 Dec 2012, at 23:41, fnu wrote: Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ... A Christmas message from Linus - "IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON" <http://article.gmane.org/gmane.linux.kernel/1414106> http://article.gmane.org/gmane.linux.kernel/1414106 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> Keep in mind, all these changes are occurring in the _developer_ version of VDR, not stable. Oh damn, I did not even realize this ... ^^ Nobody really want to use VDR 1.6.0 anymore these days, in Europe we would not be able to watch HDTV. Facing this fact VDR 1.7.3+ is more than just a developer playground. All plugins for VDR 1.6.0 are already saddled, for 1.7.x they need keep up with VDR's development, so that is not a question of choosing the wrong version. It can't be the right way that there is a VDR developer version, which is just usable from vanilla source w/o any addon and hardly in any other environment. How should anybody test it for real life, assuming that the next version does again deny all work again ... ? I don't deny changes, quite the contrary, Klaus does now it, I appreciate them. But the way of the last changes, in best manner of Louis XIV, ignoring all other needs around can't be the right way. Derek tell me, do you compile your Linux also from scratch/source? I would assume you don't do this and rather using something like Fedora, RedHat, SuSE, Debian, Gentoo etc. using comfortably the offered packages ot their repositories, even the ones from unstable sources. If I talk about distro, I do talk rather about these package offerings. I did compile my VDR from source for many years since the year 2000/2001, but I appreciate to have it as Debian package or similar later days. I would also not compile my libreoffice from source, why, it's already there. And I like to offer up to date Ubuntu packages for interessted users. VDR is indeed a success and my alltime HTPC favorite, thanks for it Klaus. But that is not from the users compiling from source. I do not talk about some dozens of US users compiling VDR themselfs from source. VDR start to get a huge distribution in Germany and later Europe from pre-packaged ISOs, like vdr4you, linvdr and especially c't-vdr (thanks Tobi and team). These days easyvdr, gen2vdr, MLD and yaVDR do provide OOTB VDRs for thousands of installations in Germany, Europe, maybe worldwide. Does anybody think these users would be interssted in VDR 1.6.0 nowadays? No, they are more than happy with these VDR 1.7.x based installations, modern and capable for HDTV and they do tell this their neighbours using any crappy satellite receiver with a lot of problems ... ;-) Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ... === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
> ... there are way too much changes at the moment :) FullAck, but the number of changes are not the issue, it's more the sustainability and the time frame within the changes. Looking to the last 5 versions, each of them do look allmost like a complete new version. There is allmost no time for other developers (plugins, addons and distros) to react to them and the worse, they don't now if their work is valid for the next vdr developer version. If you want to stop any development around VDR, go ahead like this ... But don't forget, you don't make a solution liek VDR a success or BBS like vdr-portal only with a few "make; make install" users. Over 95% of VDR users are using a distribution. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
Oliver Schinagl wrote: > Nevertheless, good to know that DVB-S2 on the ngene is well supported (I guess ) :) Yes it is, but it's a different device, so don't mix it. The kernel modules "ddbridge" or "ngene" do represent the PCIe-Bridges, not the receiving frontend. "ngene" based cards have been the former devices, with less possibilities to expand tuners, DVB-S2 only available and no CI support. The first versions of these devices has been a PCIe PCB (V5.4 and prior) with just 2 DVB-S2 tuners and no connector for additional ones. The last version (V5.5) of "ngene" based devices had also 2 DVB-S2 tuner and one connector for additional 2x DVB-S2 (Flex-Modules). I'm running a V5.5 with 4x DVB-S2 in a VDR since March 2011 connected to a SCR environment, perfect :-) "ddbridge" did enhance the possibilities. There are two different solutions out there, either the classic DVB-S2 dual-tuner PCIe similar to the V5.x ones, called V6.x. This PCIe PCB do have two connectors for Flex-Modules, which can be a single CI, dual CI, dual DVB-S2 or Dual DVB-C/T. Alternatively there are or have been the bridges only (no tuners) available, either as PCIe 1x PCB or mPCIe. AFAIK there has been two versions out, one with 2 connectors, one with 4 connectors. With the last you could build a VDR with up to 8 tuners connected to a single [m]PCIe card ... The dual Flex-Modules of the V5.5 and V6.2 are interchangable, they are bottomline the same, just normal product care over the time ... I'm running also an L4M Dual DVB-S2 V5.4 (ngene) and a V6.2 (ddbridge) in test and development maschines. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Betr: Re: my PC wakes up one hour late
Cedric, yes of course, you do use ntp, the clock runs correctly, good. But that wasn't the issue I did ask for. Using "acpiwakeup", does need to set the hardware clock to UTC timezone. So, if you don't live in Greenwich next to London or within this timezone at all, there should most probably be a difference between the hardware clock of your VDR and it's system time. If your hw clock doesn't run at UTC time, you may see wakeup shifts like you did describe it. Some hours before or ahead, where ever you're living. You can check RTC's time with the command "sudo hwclock" and check if it does run on UTC time, comparing to your systems time, according to "/etc/timezone". === Regards fnu PS.: IIRC it is possible to configure "acpiwakeup" not to need RTC in UTC, pls. check documentation for that ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] my PC wakes up one hour late
Nov 2 00:37:03 TV vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.acpiwakeup Nov 2 00:37:03 TV vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2012-11-02 Hi there, so, you use acpiwakup, therefor the hardware clock needs to be set to UTC time. What does: - hwclock say? === Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
> First, it's not true remote have followed some "master plan" for 10 years > that's RGYB. VDRs master plan, not all remotes. We are talking about VDR here ... :-( ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
> I have too.. Already for years (from 2005).. I have RGBY. It's "Silver Stone" > -case with integrated IR remote. Well then you're already used to the "wrong" mapping. I guess you'll struggle if you get the correct order, isn't it … ? SCNR … ;-) Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
> But is it really that necessary? I guess it depends on the point of view. It is right not all remotes provide the same key order, but the master plan since over 10 years is "RGYB". So if a individual doesn't want to use a remote following VDR's standard, should find a way around by themself, at least from my point of view. But hence, functionality of the color buttons remains still the same, even ist "YBRG" or what ever, pretty sure users get used to it after a while ... > I haven't seen any postings here actually supporting that idea. > The "quasi standard" sequence of the color buttons *is* RGYB... Outside OSD the color buttons can be defined freely, but inside they is kind of fixed definitons fixed for these keys by source code. Maybe the target is to get a possibilty to change these now somewhat fixed mapping, that each individual can define ther what it want to have. Even the order, to match the order on the "non-VDR" remote ... And yes, I remember 1 or 2 questions in vdr-portal regarding this ... ;-) Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Theses Client/Server VDR
Dear Tobias, this was just my vision of a Client/Server capable VDR concept. I felt urged to sketch this user friendly concept, after a similar (horrible) discussion here on mailing list, where developer did discuss complex solutions just for developers. I don't have the ability to provide a fork and honestly don't want to have one. It would rather be cool if some of the ideas become part within the one and only VDR. But I don't know if Klaus does have a sneek view into this vision at all, it's up to him. This wasn't a claim, just a sketched design study how an upcoming Client/Server capable VDR could look like on the surface. The details under the hood are far away from being specified. So, don't wait for it, even if it comes (partly) it will be a version 2.2 or further, please let Klaus finish 2.0 with all the good new features and HD capability, finally. Thanks to all, it seems the ideas did found some fellower. Cheers Frank -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Tobias Hachmer Sent: Monday, March 12, 2012 9:34 AM To: vdr@linuxtv.org Subject: Re: [vdr] Theses Client/Server VDR Hello list, this topic seems very interesting. I think it's overdue in times a lot of software is client/server oriented to conform the vdr. Are there any plans how to start with this project? Will the maintainer of vdr support this or will there be a fork? Tobias Hachmer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Theses Client/Server VDR
Nothing to complain, these thoughts do particularize my sketched vision ... ;-) -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von VDR User Gesendet: Samstag, 3. März 2012 22:24 An: VDR Mailing List Betreff: Re: [vdr] Theses Client/Server VDR Just a few quick thoughts... Clients have their own independent osd. Clients have their own display and audio settings. Clients detect disconnect-from-server and attempt reconnect. Client labels (living room, office, kids, man cave, etc) for easy maintenance & identification. Servers able to (dis)allow timer privileges (create, modify, delete) for each client. Servers able to (dis)allow recording privileges (edit, delete) for each client. Servers able to handle multiple clients that may be trying to modify/edit things such as timers & recordings. Servers should have smart device selection. For example if dvb-s is requested, use an available dvb-s device before dvb-s2. If a non-turbo fec device is requested, use an available non-turbo fec device before one that supports turbo fec. Or some method by which users can create their own device priority list. ___ 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] Theses Client/Server VDR
> Since automatism may be wrong No, absolutely not, just to keep it super simple for the user. But yes, I did imply to give interessted users the possibilty to do an override, which VDR is princible in users personal VDR cloud or the other settings. Somewhere deep in the OSD ... Regards fnu -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Lars Hanisch Gesendet: Samstag, 3. März 2012 18:51 An: vdr@linuxtv.org Betreff: Re: [vdr] Theses Client/Server VDR Hi, Am 02.03.2012 11:12, schrieb fnu: > Hi there, > > following the discussion regarding Client/Server the last couple of > day, I'm honestly horrified. > > What I did realize where super complex ideas, hacks, bottomline a > solution from developers for developers. I got the imagination some > want to keep out normal users, inventing VDR to death, because only a > few users are able to handle it. > > Since Apple pretty much come with a TV solution this year, > expectations of users will change in terms of GUI& usability. And not > only Apple, even Ubuntu does invent in the same direction on their UbuntuTV. > > There's no need to copy these solutions, but the need to be prepared > to these fast changing expectations. To think about the details of > VDR, a good and stable solution, which I love to use since over 10 years now. > > I don't have any issues to run a complete VDR on Client and Server, > the binary is small, so what. > > My dream of a Client/Server VDR solution is: > > - 1+n VDRs do find themselfs seemless w/o user interaction within a > network > - 1+n VDRs do elect/define a principle, which become the leader of the > pack, preferably that one with (the most) DVB devices Since automatism may be wrong (same number of devices in each vdr or whatever), a simple priority numbering scheme of the vdrs should be possible. Something like: "This is my main vdr (priority 100), this vdr has priority 50 etc." I think this could be handled by every user and it can be easily configured via OSD. :) Lars. > - The principle becomes the central point of VDR operation > - Timers set on whether Client/Server VDR, is handled by the principle > centrally > - Recordings are also handled centrally on the principle, the clients > do have seemless access to it > - It doesn't matter if the clients do have their own disks > - But if needed principle can use this addional disk space on clients > and each client does also have seemless access > - DVB devices can be added and removed dynamically to each of the > VDRs, but principle stay responsible for all DVB devices within > network > - Plugins can be added/removed dynamically via OSD or a Web-Interface > - The VDR pack or rather the principle can be controlled/programmed by > a cloud service from all over the world. > - Setting up one of these VDRs may only be possible for experienced > user, but es soon as they're up and running, you're little children > could hanle them. > > Just my vision for a smart client/server VDR solution. > > Cheers > fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Theses Client/Server VDR
Hi there, following the discussion regarding Client/Server the last couple of day, I'm honestly horrified. What I did realize where super complex ideas, hacks, bottomline a solution from developers for developers. I got the imagination some want to keep out normal users, inventing VDR to death, because only a few users are able to handle it. Since Apple pretty much come with a TV solution this year, expectations of users will change in terms of GUI & usability. And not only Apple, even Ubuntu does invent in the same direction on their UbuntuTV. There's no need to copy these solutions, but the need to be prepared to these fast changing expectations. To think about the details of VDR, a good and stable solution, which I love to use since over 10 years now. I don't have any issues to run a complete VDR on Client and Server, the binary is small, so what. My dream of a Client/Server VDR solution is: - 1+n VDRs do find themselfs seemless w/o user interaction within a network - 1+n VDRs do elect/define a principle, which become the leader of the pack, preferably that one with (the most) DVB devices - The principle becomes the central point of VDR operation - Timers set on whether Client/Server VDR, is handled by the principle centrally - Recordings are also handled centrally on the principle, the clients do have seemless access to it - It doesn't matter if the clients do have their own disks - But if needed principle can use this addional disk space on clients and each client does also have seemless access - DVB devices can be added and removed dynamically to each of the VDRs, but principle stay responsible for all DVB devices within network - Plugins can be added/removed dynamically via OSD or a Web-Interface - The VDR pack or rather the principle can be controlled/programmed by a cloud service from all over the world. - Setting up one of these VDRs may only be possible for experienced user, but es soon as they're up and running, you're little children could hanle them. Just my vision for a smart client/server VDR solution. Cheers fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
> about "Pause and rewind live TV". What is live TV there, as it is already recorded ... ? Only users which didn't got into VDR and epgsearch timers do call for this live buffer function. They hope for a kind of security, which this function doesn't really provide. You want to have a feeling how it feels, if a live buffer is the underlying central function in a PVR solution, just go and test MythTV. Cheers fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
Dudes, did set up a basic VDR on Ubuntu Precise yesterday and it did work as expected. Install a minimal Ubuntu from alternate installer, add "apt-get install xorg nvidia-current", VDR e.g. from our yaVDR PPA (ppa:yavdr/unstable-vdr, ppa:yavdr/main) incl. vdr-plugin-softhddevice and you're almost done. SoftHDDevice does start with this basic Xorg from Ubuntu repository, no additional WM like openbox, fluxbox, lightdm etc. needed. Ok, from this point the most work is now to set up all the odds and ends to get proper usable VDR, xorg.conf, sensors, hddtemp, remote control etc. ... ;-) Have fun. Regards fnu -Ursprüngliche Nachricht- Von: fnu [mailto:v...@auktion.hostingkunde.de] Gesendet: Dienstag, 7. Februar 2012 23:42 An: 'VDR Mailing List' Betreff: AW: [vdr] SoftHDDevice > You don't need a windows manager with xine/vdr-xine either, but according to > softhddevice own text, -f requires it. Well xorg alone would not work w/o any basic window management stuff, called it window manager or not, but bottomline it is one, included in pure xorg. If there wouldn't be a thing like this, you would not be able to open just a basic windows, like xterm. And you can do this, nowadays black on black instead of herringbone pattern, if you just install basic xorg with it's dependencies. There must be something which manages the size of the desktop, advise to open a window in a specific size on a defined position, or just fullscreen. All other stuff known as window manager just adds kind of decoration, widgets, buttons, a kind of configuration scripting etc. ... There was also no need to have an decoration manager to operate the old softdevice-plugin (SD), id did just run on the old herringbone desktop ... ;-) Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
> You don't need a windows manager with xine/vdr-xine either, but according to > softhddevice own text, -f requires it. Well xorg alone would not work w/o any basic window management stuff, called it window manager or not, but bottomline it is one, included in pure xorg. If there wouldn't be a thing like this, you would not be able to open just a basic windows, like xterm. And you can do this, nowadays black on black instead of herringbone pattern, if you just install basic xorg with it's dependencies. There must be something which manages the size of the desktop, advise to open a window in a specific size on a defined position, or just fullscreen. All other stuff known as window manager just adds kind of decoration, widgets, buttons, a kind of configuration scripting etc. ... There was also no need to have an decoration manager to operate the old softdevice-plugin (SD), id did just run on the old herringbone desktop ... ;-) Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
> -fstart with fullscreen window (only with window manager) Hmm, AFAIK xorg does come with a build in window manager, I'm not 100% sure, but I guess it's called "xwm". This provides just basic window work and I did use just pure xorg over years with the "softdevice" plugin. There was no need to install openbox, fluxbox etc. Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
> - I haven't figured out how to enter fullscreen mode. Well, AFAIK this is mentioned in the README. There are a couple of switches/options for the plugin start, one of them is "-f" for full screen. An other one is "-d" for the correct display and "-x" to start xorg by the plugin. And no, there is no need for a display manager, I wonder where you got this information ... most of us do test the plugin on existing Linux desktop installtion, because there's quit a way to go ... But VDPAU is IMHO closed to be ready for production use, but not VA-API or even XvBA ... Since author "johns" AFAIK isn't dealing with this mailing list, you could place your questions here in this tread: http://www.vdr-portal.de/board17-developer/board21-vdr-plugins/109700-softhd device-software-vdpau-va-api-cpu-decoder-und-ausgabe-plugin/?s=b83100f9ae841 a9015a5769eb450a5611c1c7cb8 Don't worry just post in english, you'll get the answer also in english. Or feel free to open a new one in english, you will get answers in english ... ;-) Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
> How about the new truecolor osd VDR has now? Well, you did ask regarding a "HD OSD" which isn't automatically a true color OSD ... Whereas AFAIK true color OSD is also possible with SD (576i) output, e.g. xine/xineliboutput. The main problem, there isn't any real true color OSD skin out there, to use it ... But the skins I did test, looked impressive with softhddevice :-) Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
> What's the url for this plugin? I would definitely like to try it! http://projects.vdr-developer.org/projects/plg-softhddevice > Does it also have a built-in media player? No, at the end the mplayer- and music-plugin will do this job > Does it support an HD osd? Where ist the difference? Plugin does support OSD size up to display resolution ... Cheers fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] where can I find a working vnsiserver
Isn't it that "vdr-plugin-xvdr" has had supersed "vdr-plugin-vnsiserver"? https://github.com/pipelka/vdr-plugin-xvdr Regards fnu -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Arturo Martinez Gesendet: Donnerstag, 19. Januar 2012 19:07 An: vdr@linuxtv.org Betreff: [vdr] where can I find a working vnsiserver where can I find a working vnsiserver for vdr 1.7.21 and current git XBMC ? ( I am looking for source code, not a .deb package) ___ 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] howto ignore lines in channels.conf
> I've been living with VDR's auto channel update quite well, back since > VDR 1.3.x eliminated the need of the AutoPID patch. I said, I can go with the thought, it should be rather a native VDR function. From the technical point of view you're right, it runs perfectly, this function for people who know what to do. But where to hack is it written down, that experts and specialist wouldn't like some comfort? Whereas this might things easier for noob's starting to become an expert ... ;-) But again, I also know this would not be easy to implement, unlike a "small" function to enable or disable an entry in channels list thru OSD. > How long does it take for it to find some channels, and how does that look like from the user POV? A couple of weeks ago I did use this feature in a friend's new installation, it took around 15-20min in the background to gather ~ 500 channels from his cable provider, while we did watch live tv in foreground. Ok, you need at least one running entry in channels list, to make it happen. But this could also be pre-defined iptv entry, like it is done w/ yaVDR ... Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] howto ignore lines in channels.conf
> At least when I started to use VDR a long time ago, channels.conf pretty much *had* to be created with tools that weren't included with VDR ("scan" or something like that from dvb-apps). > I haven't checked recently, but I suspect it's the same these days. Well that is an other question and valid argument, why is there no sufficient solution to scan for channels in VDR, like is quit normal on commercial solution. Not that I like to have a stupid on, which provides me 4000 channels from satellite, whereas only 40-80 or so are really relevent for me and do have trouble to sort it out laters, like it is also quit normal on commercial solutions. There is at a command line tool available, "w_scan" or a plugin "vdr-plugin-wirbelscan". But yes I can go with the thought, this should be rather a nativ VDR function. But this will be pretty difficult to implement, since VDR runs with a uncounted number of DVB devices. Whereas commercial solutions do need to work just with their one and only DVB device type. It doesn't matter if it is avaiblable with DVB-C/T/S receivers, it's always just one type. So the software does need to be able to run with 3 different DVB type in max. and not with a thousend or so ... Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] howto ignore lines in channels.conf
> Even though they'd get lost when VDR writes it, allowing comments there would be an improvement so distros (and VDR itself) could ship the file with some comments in it that instruct users what they need to do before things will work, or what the file is for, or... Same thing applies to remote.conf, setup.conf, and timers.conf. The mentioned files are nothing else than a table of the database VDR. There is no solution out there, where it is possible to edit the channel list outside the normal operation, or even to think about comments within it. It is not possible within MythTV, not on commercial settop boxes, PVRs or any builtin receivers in TV devices, not even with the famous DBox'es and Dreamboxes. If you're lucky there might be tool where you could connect from another PC to the box and edit your channel list within small boundaries, so advantage VDR, 15:0 ... So, the information has to be managed from datebases frontend, in case of VDR the OSD or "svdrp". The only sufficient solution might be to have a switch in OSDs channel editor, to disable or enable a entry in channels list, like it is available on commercial solutions. Same for all relevant conf-Files, whereas I don't see any reason to put comments into timers.conf, weird ... Regards fnu -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Ville Skyttä Gesendet: Sonntag, 15. Januar 2012 12:29 An: vdr@linuxtv.org Betreff: Re: [vdr] howto ignore lines in channels.conf On 2012-01-15 13:01, Klaus Schmidinger wrote: > VDR reads the channels.conf file and doesn't store any information > about "comments". It only stores the channel data. > When it writes the file, it writes only the channel data, and at that > point any comments in the original file would be lost. Even though they'd get lost when VDR writes it, allowing comments there would be an improvement so distros (and VDR itself) could ship the file with some comments in it that instruct users what they need to do before things will work, or what the file is for, or... Same thing applies to remote.conf, setup.conf, and timers.conf. If the "AllowComments" parameter exists just for the purpose of disallowing comments in files where VDR doesn't preserve them, I suggest removing that restriction altogether and allowing comments everywhere. Allowing comments and preserving them are two different things. For files where VDR doesn't preserve them it could note that on the first line of such files, for example like: # Warning: VDR will overwrite this file without preserving comments. ___ 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] Diseqc problems with VDR1.7.19
> It *is* supposed to work with any number of code sequences per entry. > BTW: I'm planning on adopting the unicable patch in the next developer version. > Just received the necessary hardware for testing this week. > Klaus Dear Klaus, thanks for your effort to enhance the functionality of VDR to common needs and feel free to come back to me in case somebody needs to test or verify things for EN50494, SCR, Unicable (TM) implementation. Since known patch only seems to work until version 1.7.18 w/o re-work, Lars tries to get it the stuff work for yaVDR w/ 1.7.20 ... and well yes, he learns a lot to understand the function and me a little bit, too. Cheers Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MaxVideoFileSize
As long as your filesystems can handle this size, you can choose it. I still use max. 1GB file size, because in of failed transfers what ever kind it is still much easier to handle than one large file ... -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Dominic Evans Gesendet: Montag, 15. August 2011 18:08 An: VDR Mailing List Betreff: [vdr] MaxVideoFileSize Apart from FAT16/FAT32/ISO 9660 compatibility reasons, are there any benefits to keeping MaxVideoFileSize for recordings at <= 2GB? I was considering setting it to something arbitrarily larger such as 16GB but just wondered if I was causing any unexpected side effects. ___ 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] resetting recordings
> What level of debugging must be enabled and what do you need to look for in the syslog to see when vdr is running a scan against the video directory? Well, none? === vdr1-vdr:/var/lib/video.00> touch .update;tail -f /var/log/syslog Apr 13 09:10:11 vdr1 vdr: [31424] video directory scanner thread started (pid=31023, tid=31424) Apr 13 09:10:11 vdr1 vdr: [31423] video directory scanner thread started (pid=31023, tid=31423) Apr 13 09:10:11 vdr1 vdr: [31424] video directory scanner thread ended (pid=31023, tid=31424) Apr 13 09:10:11 vdr1 vdr: [31423] video directory scanner thread ended (pid=31023, tid=31423) === My main VDR, version 1.7.16 ... Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] resetting recordings
If you don't have any entry for updating/re-reading recordings in you OSD, the common way is to "touch .update" in the appropiate directory of your recordings, the VDR will then re-read all recordings. Or just restart VDR services, AFAIK VDR is doing also a re-read here. -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Arturo Martinez Gesendet: Montag, 11. April 2011 11:06 An: vdr@linuxtv.org Betreff: [vdr] resetting recordings My vdr 1.7.x recordings look a bit messy. I get multiple single entries for the same show although I have put them physically on the same folder (under the _ subfolder) How can I force vdr to re-index them? ___ 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] BBC HD pixelation
> so I guess it must be a xine-lib problem? or a deinterlacing problem? Hmm, I don't see a general problem due xinelib, because a couple of guys are watching BBC HD from Astra 28.2° here in Germany. Due to it's unfavorable postion, Astra 28.2°, it is basically not easy to get, especially in the southern parts of germany, but I haven't ever heard there is a general problem with "BBC HD" using xine-lib output. I would rather guess that your setting in config do not fit for watching BBC HD. It's like in the german "ZDF HD", if you have not configured the minimum buffer setting you wouldn't get any sound, whereas "Das Erste HD" does work perfectly, even with the same low buffer settings, ..., so, there are couple of suggestions for these settings, where you may have look at it? Regards fnu -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Daniel Harris Gesendet: Samstag, 9. April 2011 22:27 An: VDR Mailing List Betreff: Re: [vdr] BBC HD pixelation On Sat, Apr 9, 2011 at 8:05 PM, Klaus Schmidinger wrote: > > > > > On 09.04.2011, at 19:03, Daniel Harris wrote: > >> Hello >> >> I am currently experiencing picture pixelation when watching the BBC >> HD station. I have tried changing the position of the dish changing >> deinterlace settings even sending 1080i output to the tv and tuned >> several paramaters within my xineliboutput config but this seems to >> have no effect. The problem does not occur when watching ITV HD so I >> am confused as to what is causing it. Is anyone watching freesat BBC >> HD perfectly and is so how are you doing it. I have read that other >> people have had similar problems but that seems to be a few years >> back so I am not sure if this is a bbc problem a vdr problem or a >> xine problem. I would appreciate any help in fixing this. > > I just watched BBC HD live for a couple of minutes and it was totally fine. > > Klaus > > Thank You both for the response, that has cleared thinks up a bit. vdr using xineliboutput plays BBC HD live pixelated, plays the recording pixelated but mplayer plays the file with no pixelation. so I guess it must be a xine-lib problem? or a deinterlacing problem? I will give the xine-plugin a try Thanks again Dan > ___ > 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] [Patch] Make RGYB buttons customizeable
=== Your theory that the RGYB color scheme is a worldwide standard with only cheap obscure non-media remotes being 'non-compliant' has already been thrown out the window. I don't know why you think pasting a link to an Italian website can somehow resurrect the dead theory. Btw, no link you ever paste will outweigh what color scheme people see on their physical remotes. If you want to argue about it further then contact Panasonic, Sony, and your friends at Logitech to start with. === Well, that's a claim. It's not just any italian URL, this is the main page of the inventor and license holder for "TOP Teletext". This is the company where all manufacturer do pay their license fees to, if their TV set do provide this function. The invention of T(able) O(f) P(ages) Teletext brought us the colored keys on TV remotes 25 years ago, not surprisingly in the order R(ed) G(reen) Y(ellow) B(lue). Fifteen years later, Klaus adopt these common keys and standardized this order, RGYB, for his awesome and incredible solution VDR, as they are anywhere available, except on some trashy ones ... Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
Hi there, to finish discussion if RGYB ist a standard or not or where does it come from: - http://www.topteletext.com/en.asp - http://www.topteletext.com/working/ Regards fnu -Ursprüngliche Nachricht- Von: fnu [mailto:v...@auktion.hostingkunde.de] Gesendet: Sonntag, 3. April 2011 16:57 An: 'VDR Mailing List' Betreff: AW: [vdr] [Patch] Make RGYB buttons customizeable Well, not only the German one's, there was also a Screenshot from Norway, I guess a kind of advanced teletext: http://upload.wikimedia.org/wikipedia/en/d/d0/Digital_teletext_%28NRK%29.jpg Regards fnu -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Klaus Schmidinger Gesendet: Sonntag, 3. April 2011 12:55 An: vdr@linuxtv.org Betreff: Re: [vdr] [Patch] Make RGYB buttons customizeable On 01.04.2011 15:26, Oliver Schinagl wrote: > I have a iMon remote control, which also doesn't use this 'standard' > order ;) > > Additionally on my previous mail (I hit send by accident actually :p) > I checked the wikipage, and i couldn't find any mention of color or > colour in relation to the order of the buttons. Also searching for > Yellow didn't result in a single hit, nor did RGYB. I guess he was referring to the screen shots on that page: http://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Teletext_level1_0_l ebel2_5.jpg/500px-Teletext_level1_0_lebel2_5.jpg http://upload.wikimedia.org/wikipedia/en/thumb/d/d0/Digital_teletext_%28NRK% 29.jpg/250px- Digital_teletext_%28NRK%29.jpg Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
Well, not only the German one's, there was also a Screenshot from Norway, I guess a kind of advanced teletext: http://upload.wikimedia.org/wikipedia/en/d/d0/Digital_teletext_%28NRK%29.jpg Regards fnu -Ursprüngliche Nachricht- Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Klaus Schmidinger Gesendet: Sonntag, 3. April 2011 12:55 An: vdr@linuxtv.org Betreff: Re: [vdr] [Patch] Make RGYB buttons customizeable On 01.04.2011 15:26, Oliver Schinagl wrote: > I have a iMon remote control, which also doesn't use this 'standard' > order ;) > > Additionally on my previous mail (I hit send by accident actually :p) > I checked the wikipage, and i couldn't find any mention of color or > colour in relation to the order of the buttons. Also searching for > Yellow didn't result in a single hit, nor did RGYB. I guess he was referring to the screen shots on that page: http://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Teletext_level1_0_l ebel2_5.jpg/500px-Teletext_level1_0_lebel2_5.jpg http://upload.wikimedia.org/wikipedia/en/thumb/d/d0/Digital_teletext_%28NRK% 29.jpg/250px- Digital_teletext_%28NRK%29.jpg Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
> Regardless, users always have the option to patch the feature in if it > doesn't become a part of VDR's core. Here we go! Provide a patch, users can use or not w/o assuming to change vdr-core. Like the majority of users, I do use remotes following kls's VDR standard defined a century ago. I don't want to bothered w/ configurable colored keys, it can be just another cause for malfunctions, mere you guys are not willing to buy a remote which is compatible w/ VDR's standard. This is IMHO not a to high expectation, because you also buy DVB devices which are compatible w/ VDR ... If remotes would be some very expensive devices, I may follow your arguments, but you guys do often buy the cheapest you can get and expect that core VDR will changed to be usable with these sometimes pulpy devices, wereas also compatible devices are available for the same price ... Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
vdr-user: > That's definitely not true. I have about 8 different remotes and at least > half don't use that button order. In addition, not every remote has color > buttons 4 in a row. Plenty of them make a square around other buttons such > as 'ok/enter' for example. Oliver Schinagl: > I wasn't aware that the order of buttons was standarized on remotes === Well, could be that not all remotes for each pinchy device might provide color keys at all or in this order. But if they are somehow TV oriented, they follow this order in a global manner, even the M$ ones, if they have colored keys. You want an evidence? Just check out the universal remotes form the big three manufactures, Philips, Logitech & One-for-All, if the devices do offer colored keys, the order is RGYB, nothing left, nothing right, and you should really ask yourself, why? And, the most important point, global standard or not, it has been defined as standard in VDR a century ago, and this is a fact. Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
> My remote has the color order Yellow, Red, Blue, Green (only an example, i dont have the remote at hand). Lets say the buttons are Button0, Button1, Button2, Button3 > My (and perhaps only my) opinion is that vdr should request the leftmost color button, then the color right next to it (and so on) while learning. The color displayed in the osd should be assigned via the setup menu. Are you seriously asking for a major change like this, just for your most propably unique remote control? The color order of the RGYB buttons is a common standard, defined for Teletext centuries ago. So, 99.999% of all remotes providing these keys do have this order. http://en.wikipedia.org/wiki/Teletext Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr