Re: [vdr] skipping 5/10 seconds
Peter Münster writes: > Hi Klaus, > > What about adding a possibility to skip ±5 or ±10 seconds when replaying > a recording? > > Would you perhaps accept a patch for the developer version? Bonjour, i've added this to menu.c : case k5|k_Repeat: case k5: SkipSeconds(240); break; case k1|k_Repeat: case k1: SkipSeconds(-10); break; case k3|k_Repeat: case k3: SkipSeconds( 10); break; k5 to skip itv adverts when watching corrie recordings :) I've been too lazy to think of a configurable way of doing it. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
Manuel Reimer writes: > Hello, > > with event based init systems (in my case systemd) it seems to become > a big issue to startup VDR. > > If you install VDR on a SSD device, then startup gets *really* > fast. Sometimes that fast, that VDR starts before all devices are > initialized. > > I've asked in the systemd mailinglist, if there is any way to get > around this: > > http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html > > The result: The "daemon" (VDR) needs some way to detect devices while > runtime. > > So my question to Klaus: Is there something like this planned or would > a patch be accepted which adds a feature like this? As far as I know a > new dependency (libudev) would be needed. Hi, You should be able to achieve this using the dynamite patch and plugin. I would definitey love to see its features merged in main vdr btw :) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR without device
Marx writes: > Is it possible to start VDR without any device? > Why? Because I want it to serve recordings via VNSI to XBMC > Marx Hi, vdr-dummydevice Written by: Petri Hintukainen Project's homepage: http://phivdr.dyndns.org/vdr/ Latest version available at: http://phivdr.dyndns.org/vdr/ See the file COPYING for license information. Description: Output device that does nothing. All data is silently discarded. This plugin can be used to run vdr as recording server without any output devices. -- ___ 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
"fnu" writes: >> 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 ... oh i guess so :) > 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 ... those are pretty valid points. i don't use any translation myself, from computer to phone it's all in English. > 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 ... looks nice, vdrportal.de also looks nice rich and lively. unfortunatly it's in Deutsch ! :) -- ___ 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
Marc writes: > On 12/02/2013 02:24, syrius...@no-log.org wrote: >> Bernard Jaulin writes: >> >> >> Bonjour, >> >>> We are working on that now ! We send you a new one .po asap. >>> Dear french fellow countryman please take a look here : >>> http://dvbkivabien2.info/viewtopic.php?f=21&t=14987 >>> and here : >>> http://lite.framapad.org/p/ClyUvioD5s >> Thanks Bernard ! >> I've just proposed some changes on the pad as well as comments on some >> weird translations. >> >> one of the worst one is definitely "epg scan timeout", it shouldn't >> translate to "epg scan length/duration" in french ! :-) > Hi Syrius, > > Sorry if I don't have a perfect French. By "Temps de mise à jour du Why the rush in willing to translate the po on your own then ? and why the hell are you using this "sorry it's not my fault i'm not perfect" kind of excuse ? this bit is just the worst translation ever, deal with it ! (not smiling anymore) > guide (h)", I mean the time before the epg is updated. I agree, a more > correct version would be "Temps *avant* mise à jour du guide (h)" at least. > witch is IMHO what this parameter is intended for. The user inactivity > part is not mentioned in the original message, I don't see why it > should be in the translation. For a standard user "Inactivité avant just carry on using google translate then, who cares about the meaning of it anyway ! (sarcasm) > rech. EPG (h)" mean nothing IMHO. At least, the translation should > mention that this is the *user* inactivity but even with that, I'm > not > sure a standard user would understand what this parameter is about. Agreed, users shouldn't have to fallback to english to make sense of it ! Klaus, ever thought of adding help/descriptions for every menu entries and a generic button/key (à la F1) to trigger the help OSD ? It's definitely difficult to provide short translations of short english technical keywords and sentences. does that make any sense ? ;-) -- ___ 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
Bernard Jaulin writes: Bonjour, > We are working on that now ! We send you a new one .po asap. > Dear french fellow countryman please take a look here : > http://dvbkivabien2.info/viewtopic.php?f=21&t=14987 > and here : > http://lite.framapad.org/p/ClyUvioD5s Thanks Bernard ! I've just proposed some changes on the pad as well as comments on some weird translations. one of the worst one is definitely "epg scan timeout", it shouldn't translate to "epg scan length/duration" in french ! :-) the MANUAL file from vdr source tree should be giving most of the explanations and contexts. (et pourquoi ne pas commencer par la traducton du MANUEL ? :-)) -- ___ 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
Marc writes: > On 09/02/2013 15:35, Klaus Schmidinger wrote: >> VDR is now approaching version 2.0.0, so this might be a good time >> for translators to complete the internationalized texts. > Hi, > > Here is a patch for fr_FR.po. NAK NACK NON NEIN NICHT NO :-) > Regards, > > Marc. Hi Marc ! :) > > --- vdr-1.7.37/fr_FR.po 2013-02-09 14:57:00.0 +0100 > +++ vdr-2.0.0/fr_FR.po2013-02-10 16:47:46.0 +0100 > @@ -14,8 +14,8 @@ > "Project-Id-Version: VDR 1.6.0\n" > "Report-Msgid-Bugs-To: \n" > "POT-Creation-Date: 2013-02-03 16:46+0100\n" > -"PO-Revision-Date: 2008-02-27 18:14+0100\n" > -"Last-Translator: Jean-Claude Repetto \n" > +"PO-Revision-Date: 2013-02-10 16:47+0100\n" > +"Last-Translator: Marc Perrudin \n" > "Language-Team: French \n" What about talking about this translation on the french forum dvbkivabien2 ? It definitely needs corrections and testing ! (etherpad ?) > "Language: fr\n" > "MIME-Version: 1.0\n" > @@ -32,7 +32,7 @@ > msgstr "Impossible d'utiliser le mode transfert !" > > msgid "off" > -msgstr "off" > +msgstr "" Que cela implique-t-il ? > msgid "on" > msgstr "" > @@ -47,10 +47,10 @@ > msgstr "Polarisation" > > msgid "System" > -msgstr "" > +msgstr "Système" > > msgid "Srate" > -msgstr "Fréq. symbole" > +msgstr "Srate" le but n'est-il pas de fournir une traduction française ? > msgid "Inversion" > msgstr "Inversion" > @@ -77,254 +77,254 @@ > msgstr "Hiérarchie" > > msgid "Rolloff" > -msgstr "" > +msgstr "Rolloff" > msgid "PlpId" > -msgstr "" > +msgstr "PlpId" > > msgid "Starting EPG scan" > msgstr "Mise à jour du guide des programmes" > > msgid "Content$Movie/Drama" > -msgstr "" > +msgstr "Film/Drame" drama ne veut pas systématiquement dire drame. > msgid "Content$Detective/Thriller" > -msgstr "" > +msgstr "Policier/Suspence" > > msgid "Content$Adventure/Western/War" > -msgstr "" > +msgstr "Aventure/Western/Guerre" > > msgid "Content$Science Fiction/Fantasy/Horror" > -msgstr "" > +msgstr "Science Fiction/Fantasy/Horreur" > > msgid "Content$Comedy" > -msgstr "" > +msgstr "Comédie" > > msgid "Content$Soap/Melodrama/Folkloric" > -msgstr "" > +msgstr "Soap/Mélodrame/Folklorique" > > msgid "Content$Romance" > -msgstr "" > +msgstr "Romance" > > msgid "Content$Serious/Classical/Religious/Historical Movie/Drama" > -msgstr "" > +msgstr "Averti/Classique/Religieux/Film Historique/Drame" Averti ? pourquoi pas Sérieux tout simplement ? voir dur, rude, avisé, ... > msgid "Content$Adult Movie/Drama" > -msgstr "" > +msgstr "Film pour adulte/Drame" > > msgid "Content$News/Current Affairs" > -msgstr "" > +msgstr "Informations/Actualités" > > msgid "Content$News/Weather Report" > -msgstr "" > +msgstr "Information/Météo" plus de s à information ? > msgid "Content$News Magazine" > -msgstr "" > +msgstr "Magazine d'information" > > msgid "Content$Documentary" > -msgstr "" > +msgstr "Documentaire" > > msgid "Content$Discussion/Inverview/Debate" > -msgstr "" > +msgstr "Discussion/Interview/Débat" > > msgid "Content$Show/Game Show" > -msgstr "" > +msgstr "Spectacle/Jeu Télévisé" > > msgid "Content$Game Show/Quiz/Contest" > -msgstr "" > +msgstr "Jeu Télévisé/Quiz/Concours" > > msgid "Content$Variety Show" > -msgstr "" > +msgstr "Spectacle de variétés" > > msgid "Content$Talk Show" > -msgstr "" > +msgstr "Débat télévisé" > > msgid "Content$Sports" > -msgstr "" > +msgstr "Sports" > > msgid "Content$Special Event" > -msgstr "" > +msgstr "Événement spécial" > > msgid "Content$Sport Magazine" > -msgstr "" > +msgstr "Magazine sportif" > > msgid "Content$Football/Soccer" > -msgstr "" > +msgstr "Football/Foot" > > msgid "Content$Tennis/Squash" > -msgstr "" > +msgstr "Tennis/Squash" > > msgid "Content$Team Sports" > -msgstr "" > +msgstr "Sports d'équipe" > > msgid "Content$Athletics" > -msgstr "" > +msgstr "Athlétismes" sans s je dirais > msgid "Content$Motor Sport" > -msgstr "" > +msgstr "Sport mécanique" en français le tout est souvent au pluriel > msgid "Content$Water Sport" > -msgstr "" > +msgstr "Sport nautique" pareil > msgid "Content$Winter Sports" > -msgstr "" > +msgstr "Sports d'hiver" étrange ! la il y a un s :) > msgid "Content$Equestrian" > -msgstr "" > +msgstr "Équitation" > > msgid "Content$Martial Sports" > -msgstr "" > +msgstr "Sports Martiaux" Bon la c'est dur, sport martial ca n'existe pas :) c'est sport de combat ou art martial :) (quoi qu'il en soit en effet c'est au pluriel :)) > msgid "Content$Children's/Youth Programme" > -msgstr "" > +msgstr "Enfant/Programme jeunesse" > msgid "Content$Pre-school Children's Programme" > -msgstr "" > +msgstr "Programme pour enfant de maternelle" pour un seul enfant ? :-) > msgid "Content$Entertainment Programme for 6 to 14" > -msgstr "" > +msgstr "Programme de divertissement pour les 6/14 ans" (ici c'est bien pour plusieurs enfants) > msgid "Content$Entertainment Programme for 10 to 16" >
Re: [vdr] tvguide 0.0.1
syrius...@no-log.org writes: > louis.br...@gmx.de writes: > >> Hi, >> >> I'm the author of the plugin. You have to use a true color capable output >> device (i 'm using softhddevice, but it should also work with xine, or >> xineliboutput with HUD enabled) to run the plugin. > > Ok. > Thanks for the information guys. > I don't know if my gfx card supports xrender/composite, i'll give it a > try this evening. still i'm kind of worried, the plugin makes vdr crash very badly. I'm using xineliboutput, my vdr server is headless and I'm watching tv over the network using old laptops as TVs (heh no big display here, the bigger one is 15inches wide !!!) That means any non-hud-enabled client will crash vdr because of tvguide. Still I'm going to give this hud/composite thingy and your plugin a try ! That might convince us to upgrade :-) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] tvguide 0.0.1
louis.br...@gmx.de writes: > Hi, > > I'm the author of the plugin. You have to use a true color capable output > device (i 'm using softhddevice, but it should also work with xine, or > xineliboutput with HUD enabled) to run the plugin. Ok. Thanks for the information guys. I don't know if my gfx card supports xrender/composite, i'll give it a try this evening. is there a public repo for tvguide btw ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] tvguide 0.0.1
Hi, I've just discovered tvguide on vdr-developper.org. I'm running vdr 1.7.31. i followed the instructions, copied the themes files to $VDRCONF/themes. When i try to use the plugin I get nothing (osd goes away). vdr control doesn't work anymore so i guess the plugin is activated. And vdr segfaults when i press OK. I don't have any channellogos or epgimages, the plugin is run with no option. The README file doesn't tell much about theses images anyway. (format, filename, examples files, etc... nothing) vdr-tvguide-0.0.1.tgz seems to date from september, is there a public repo for this plugin ? logs: vdr: [7439] tvguide: Rendering took 0 ms vdr[7439]: segfault at 20 ip 7f494f59254e sp 7fff4b73be80 error 4 in libvdr-tvguide.so.1.7.31[7f494f581000+1b000] config: OSDSkin = sttng OSDTheme = default tvguide.bigStepHours = 3 tvguide.channelCols = 5 tvguide.displayTime = 160 tvguide.epgImageHeight = 240 tvguide.epgImageWidth = 315 tvguide.fontButtonSize = 33 tvguide.fontDetailHeaderSize = 40 tvguide.fontDetailViewSize = 33 tvguide.fontGridSize = 27 tvguide.fontGridSmallSize = 24 tvguide.fontHeaderSize = 33 tvguide.fontIndex = 0 tvguide.fontMessageBoxLargeSize = 40 tvguide.fontMessageBoxSize = 33 tvguide.fontTimeLineDateSize = 33 tvguide.fontTimeLineTimeSize = 0 tvguide.fontTimeLineWeekdaySize = 40 tvguide.footerHeight = 80 tvguide.headerHeight = 120 tvguide.hideChannelLogos = 1 tvguide.hideEpgImages = 1 tvguide.hugeStepHours = 24 tvguide.jumpChannels = 5 tvguide.logoExtension = 0 tvguide.logoHeight = 73 tvguide.logoWidth = 130 tvguide.roundedCorners = 0 tvguide.themeIndex = 1 tvguide.timeColWidth = 120 tvguide.timeFormat = 1 tvguide.useBlending = 1 -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
Mariusz Bialonczyk writes: > On 01/03/2013 02:09 PM, syrius...@no-log.org wrote: >> I'm not using the xvdr plugin, what would be the equivalent workaround >> for vdr itself ? > > The equivalent in VDR should be this: > http://pastebin.com/raw.php?i=RnW6p5gt Thanks Mariusz ! Giving it a try right now. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
Mariusz Bialonczyk writes: > On 11/10/2012 12:12 AM, Mariusz Bialonczyk wrote: >> Is it possible that it is caused by some global lock or mutexes >> in VDR? > > Hello > It seems the cause of the problem has been located by Alex Pipelka. > > The vdr freezes occurs when obtaining the signal strength/quality > with functions SignalStrength() and/or SignalQuality() > and when non-busy adapter has tunining issues > (frontend x/x timed out while tuning to channel ...). > It occurs only on multi adapters systems (one adapter is doing > EIT scan and the other is used, eg for a live-tv). > > Guys, any thoughts on this? > I think it may be even kernel/drivers related issue. > > some details in commit discussion: > https://github.com/pipelka/vdr-plugin-xvdr/commit/d3982714 Hi, I'm experiencing a similar issue, i have 3 dvb-s cards. I'm not using the xvdr plugin, what would be the equivalent workaround for vdr itself ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] the great dynamite plugin ! :)
Hi, Talking about dynamite, I'm using it because of my dvb-ttpci card and my usb dvb-t dongle. Their driver/firmware need to be reloaded from time to time. There're 3 dvd-s cards and 1 dvb-t usb stick. I'm using the adapter_nr module feature to order the cards. - card 0 : WinTV-NOVA-HD-S2 (uses diseqc, can receive S28.2E and S19.2E) - card 1 : WinTV-NOVA-S (uses diseqc, can receive S28.2E and S19.2E) - card 2 : FF Rev. 1.5 (uses diseqc, can receive S28.2E) - card 3 : rtl2832u I'm using udev rules to configure the timeout and to pass an argument to the timeout_handler. I'm using vdr 1.7.30 atm, I've been observing one weird behaviour for quite a long time now: after I watch a recording my dynamite-patched-vdr often reloads card #0 for no apparent reason. When the recording ends, i get a black screen instead of live tv. After the timeout my handler script detach the card from vdr, reloads the dvb driver and reattach the card. After the card is detached vdr automatically switches to another card, that's an expected behavior. After the card is reattached i can use femon to switch back to card #0: it's working again. So you would say: buggy driver. But lately i've been commenting out the driver reload part in my handler script: to fix the black screen you just have to detach the card from vdr then reattach it. (nothing more) So I guess it's rather an issue with the dynamite patch, have you ever encountered it or a similar behavior ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
Tobi writes: > On 12.08.2012 14:32, Klaus Schmidinger wrote: > >> Do you actually *have* a remote control with "non-standard" color keys? > > I use an UR-2400 - R/Y/B/G. > > ...but I got used to it. Same here, RYBG. I'll give the patch a try this evening. Thanks -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] same channel on different hardware
Marx writes: > Hello > Let's say I have same channel available from DVB-S and DVB-T. Is it > possible to tell VDR that those channels are the same and can be > treated the same as on dual head DVB-S devices? > So It would share EPG and would be used for recording if needed. > There probably would be need to do some prioritizing which device > would be used as first choice. Hi, No at all, this has been on the wish list for a long time though :-) maybe for vdr 2.1 :) As far as i know, there's no official ticket/issue/wishlist tracker or development repository for main vdr. If you want to have a look at the wishes and patches you'll have to dig the mailing list archives. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Segfault in dvbhddevice
Lars Hanisch writes: > Am 07.03.2012 21:43, schrieb Udo Richter: >> Am 07.03.2012 21:19, schrieb Richard Scobie: >>> I have found that adding a "sleep 5" to my startup script, between >>> loading the drivers and starting vdr, has caused it to successfully >>> survive five reboots. >> >> I'm doing an udevadm settle --timeout=30 after load/unload, haven't had >> any issues with that. Before I had that solution, I was polling for all >> devices to appear under /dev/dvb, before starting VDR. > > "udevadm settle" is a nice replacement for a sleep, something learned today, > thanks. :-) > > ;-) > This is where the dynamite-plugin comes in (needs a patch for the > vdr). It creates device-proxies so vdr can start without the actual > devices. dynamite listens on udev and attachs the devices as they got > created. > This scenario was one of the reasons to develop that plugin... > I use it because it adds ways to detach cards from vdr, reload drivers and use them again without stopping vdr. Thanks again for this wonderful plugin ! btw, i haven't tested, does vdr-1.7.24-dynamite-subdevice.patch apply on 1.7.26+(patches from the ml) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
"Timothy D. Lenz" writes: [...] > A problem I have run into before is not that a channel is down, though > that also happens, but that a tuner is down. I've had tuner crashes, > but vdr just stayed with that tuner/chanel and recorded nothing. I > currently have 5 ATA tuners. 2 Dual tuner cards and a single. You might want to have a look at the wonderful dynamite patch and plugin: http://projects.vdr-developer.org/projects/plg-dynamite -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do not reinvent the whole wheel
Paul Menzel writes: > Am Donnerstag, den 01.03.2012, 15:31 +0100 schrieb Gero: >> On Thursday 01 March 2012 - 10:31:37, Paul Menzel wrote: >> > On Thursday 01 March 2012 - 07:03:03, VDR User wrote: >> > >> > I just want to throw in, that there are several programs already using a >> > client/server approach (MythTV [1], Tvheadend [2], …) and we should not >> > reinvent the wheel when designing the new implementation. >> >> I'd like to oppose headline and last statement. >> >> "We" can do better, so let's go ahead :) > > It looks like my message was not clear enough. I meant we should look at > what other projects implemented and tried and take the good ideas and > use those. So of course the result will probably be better. > > But cooperation like on using already existing protocols would be a big > advantage, because in this way already existing clients or servers can > be used to or tested against. Do you also imply the use of things like git/github ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Eric Valette writes: > On 02/28/2012 03:08 PM, Gero wrote: > >> ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, >> so I think it could be a good template for future vdr-development, but not >> serve as a vdr-replacement. > > Well openelec distrib does have means to use tvheadend... > >> At least I think, that OSD is a must have. > > I prefer to have it in a front end that is able to manage a > sophisticated remote correctly. what do you use as a frontend ? xbmc, showtime ? is it possible to have multiple independant osd ? i like the xine and xinelibouput plugins way a lot, on my laptop no need to install a huge (and sometimes bloaty) media center, just have to run xine or vdr-sxfe and it comes with tv+osd+remote. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Intelligent management of simulcast DVB-S2 / DVB-T channels
Udo Richter writes: > Am 23.02.2012 19:36, schrieb Magnus Hörlin: >> This is an interesting topic and I have had exactly the same ideas. But >> I think this violates Klaus's "Keep it simple" philosophy and (as usual) >> I tend to agree with him. > > If you've ever read the algorithm that picks the best possible device > for a recording, you'd probably agreed that we're already way too far > from keeping it simple. These rules are already way too complex. Adding > the complexity of choosing from different quality sources and > up/downgrading other receivers would probably push this a lot further > towards insanity. Even without the primarylimit it's still deadly complex. The very clever programming syntax used for the device selection makes it very difficult to understand and also to debug. I have an old idea in my head but I've never taken the time to do so, it's also quite erratic: disable channel and device management and allow an external program to decide how to deal with devices and channels. I wouldn't want to start from scratch and work around dvbstreamer, vdr and its plugins are wonderful ! I love it ! (it's just the device and channel management that are too limited imho) I'm not really into C++, it might already be possible to let plugins take over the channel and device management but i doubt it. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ***UNCHECKED*** Re: preventing vdr from using a device to record
Reinhard Nissl writes: >> I'd like to prevent vdr from using it for recordings. >> Do you know of any plugin or patch that help achieving this ? >> >> Ideally I'd love to be able to set priorities and properties to >> devices. >> Something like: >> device #1: can_record, can_do_epg_scan, can_do_liveview, devprio=100 >> device #2: can_record, can_do_epg_scan, can_do_liveview, devprio=90 >> device #3: can_do_liveview, devprio=10 >> >> Is there a way for plugins to alter *cDevice::GetDevice behavior ? >> Are there any plans on that matter ? > > Please modify the attached plugin, telling that device 3 doesn't > provide any transponder. Hi, Thanks, I'll give it a try. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
VDR User writes: > On Sun, Apr 17, 2011 at 2:36 AM, wrote: >> vdr-sxfe output complains it can't demultiplex the stream, but that >> won't work when I'm away and nobody's watching tv. That won't prevent >> vdr from using the bad card. > > If the vdr-sxfe log gives you useful text for this, why can't you > simply write a script that runs in the background and checks for such > text every X seconds. If the text is found, it can do whatever you > normally do to fix the problem. > > I do something similar to detect xine crashes and it works fine. > Although my preference would be the "buffer usage: 100%" crash would > be fixed once and for all. ;) But that's another issue.. Thanks for your answer, but you should reckon that checking vdr-sxfe won't help preventing vdr from using a crashed card for the timed recordings. I could do something similar if the driver was reporting that the card had crashed, and thanks to the dynamite patch I could remove the device, reload the driver and re-insert it. I'm going to patch getdevice so that the faulty card is only used for live view. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
Klaus Schmidinger writes: > You could start by patching the function > > cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, > bool LiveView) ok thanks, that's what i thought. > But wouldn't it be better to just replace that faulty > device altogether? it's a dvb-ttpci rev1.5 card, i'll try the full-ts mod. I haven't planned to buy a new card yet, I'd rather patch and get dirty with vdr :-) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
VDR User writes: > On Sat, Apr 16, 2011 at 7:28 AM, wrote: >> I'm now running one vdr instance with 4 dvb devices. >> One device is crashing quite often and I haven't find a way to >> automatically detect when it's crashed. (vdr used to issues "unknown >> picture type message in the past) > > If you're not seeing anything useful to your VDR log to determine if > the card has crashed, you may want to look at dmesg to see if > something in there could be used. Some years ago vdr was reporting the bad picture types when they occured. Now i've got no means to detects them on the server (neither in vdr logs nor in kernel messages) vdr-sxfe output complains it can't demultiplex the stream, but that won't work when I'm away and nobody's watching tv. That won't prevent vdr from using the bad card. My question still remains :) I don't mind patching vdr (changing getdevice or something else). If there's no existing patch or plugin, could you give me some input on what to change to prevent vdr from using one card for recordings and epg scans ? TIA. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] preventing vdr from using a device to record
Hi, I'm now running one vdr instance with 4 dvb devices. One device is crashing quite often and I haven't find a way to automatically detect when it's crashed. (vdr used to issues "unknown picture type message in the past) I'd like to prevent vdr from using it for recordings. Do you know of any plugin or patch that help achieving this ? Ideally I'd love to be able to set priorities and properties to devices. Something like: device #1: can_record, can_do_epg_scan, can_do_liveview, devprio=100 device #2: can_record, can_do_epg_scan, can_do_liveview, devprio=90 device #3: can_do_liveview, devprio=10 Is there a way for plugins to alter *cDevice::GetDevice behavior ? Are there any plans on that matter ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] dynamite plugin
"L. Hanisch" writes: Hi, >> It is working perfectly, i haven't tried to remove/add adapter yet. >> I will do later today. > > Thanks for testing this! No issues with detaching and reattaching, that's a very nice feature ! >> Just another question: >> When i decide to only use one vdr instance, i'll be needing the diseqc >> trick in diseqc.conf (the one that replaces the sourcecaps patch), how >> do you think it could work ? >> I guess the quickest workaround would be to add a new udev param to >> force the card index in vdr. > > I only have DVB-C and only limited knowledge about DVB-S, Diseqc and > all this stuff. But I found a description of the sourcecaps > patch. When I have read and understood it, I'll get in touch with you. > It seems possible to configure this via udev and solve it with a > device hook. But I haven't tried it and don't know exactly how the > device hooks works. (a little bit of brainstorming) Ok, Thanks again for that. I wish i wasn't that clueless about c++ and vdr internals. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] dynamite plugin
"L. Hanisch" writes: >> - have you considered changing the way vdr detects adapter on startup ? >>for instance vdr won't detect /dev/dvb/adapter1 if >>/dev/dvb/adapter0 does not exist. this might happen when using udev >>rules and restarting vdr while a module isn't loaded > > dynamite 0.0.6 now uses udev device enumeration to detect all dvb frontends > regardless of their numbering. > If you would like to keep an adapter from being used by vdr you can set an > udev environment property on that device. Hi ! Thanks a lot ! I'm using 0.0.6b and the new udev rules. My setup is : - first vdr (the one in production that has to be working, especially when i'm not @home) genuine vdr 1.7.17, 2 dvb-s cards, diseqc - 2nd vdr dynamite vdr 1.7.17, 1 dvb-s ff card which keeps crashing + 1 dvb-t usb stick It is working perfectly, i haven't tried to remove/add adapter yet. I will do later today. Just another question: When i decide to only use one vdr instance, i'll be needing the diseqc trick in diseqc.conf (the one that replaces the sourcecaps patch), how do you think it could work ? I guess the quickest workaround would be to add a new udev param to force the card index in vdr. I've been having issues with udev rules to order dvb devices in the past, instead i'm using a simple simple script that gives vdr the correct card number. ex: vdr $(get-dvb-device.sh main) "get-dvb-devices.sh main" returns "-D 1 -D 4" for example. that way i'm sure my main vdr always uses my two stable dvb-s cards -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] dynamite plugin
"L. Hanisch" writes: > Features: > - attach/detach devices [...] > - set device on idle [...] > - GetTSPacket timeout > It is possible to set a 'GetTSPacket' timeout on the devices. If a > device delivers no data for some time it can be automatically > detached. This is intended for devices which has known unstable > drivers. After detaching such a device a script is started so the > driver can be reloaded and the device can be attached again to the vdr > (this could happen on its own if the created frontend is signaled by > udev). > It avoids restarts of vdr and interrupting recordings on other devices. Thanks for that ! I'll be trying your patch this week end ! This is probably one of my most wanted vdr feature and it sounds like you've just implemented it :) questions : - have you considered changing the way vdr detects adapter on startup ? for instance vdr won't detect /dev/dvb/adapter1 if /dev/dvb/adapter0 does not exist. this might happen when using udev rules and restarting vdr while a module isn't loaded - what about being able to use aliases like /dev/dvb/dvb_s2_card_one with the -D arg ? (tho it's not really important) - what about a github tree of vdr with your patch already applied ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.16 FF card crashes
Udo Richter writes: > Am 09.02.2011 21:13, schrieb - -: >> I upgraded my VDr system from 1.6.0 to 1.7.16. After upgrade, I found >> that my FF card (fujitsu-siemens dvb-c) crashes almost every time >> when I exit from a recording playback. > > Using 1.7.16 on an unmodified FF DVB-S regularly, no special issues. > Rock solid as usual, as long as you don't do transfer mode on high > bandwidth channels. Hi, Are you still using it as a primary device with its mpeg decoder and video output ? I've been trying to use it in transfer mode only for a long time and it has been recurrently crashing. (need to unload/reload dvb-ttpci, in some rare case need to restart computer) This is an old rev1.5 card, I guess it was never meant to be used like this. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.16 FF card crashes
"Hawes, Mark" writes: > I'm have been using a Technotrend FF sat card on 1.7.16 without a > problem. > > Check you are using the latest firmware. :-) Ok, i'll give it a last try with another motherboard and also with vdr-1.6.0 and I'll give it away. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.16 FF card crashes
VDR User writes: > I've got a couple FF cards that work fine, although I've used them as > budget cards ever since I moved to a VDPAU setup. Hi, do you mean you have modified your ff card as explained on http://www.linuxtv.org/wiki/index.php/DVB_TT_Budget_Patch ? Do you use to have arm crashes or/and "unknown picture type" errors before ? I have also considered modifying my ff card but i'm not sure if it will fix my issues. Any advice or feedback on that matter would really be helpful. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.16 FF card crashes
- - writes: > I upgraded my VDr system from 1.6.0 to 1.7.16. After upgrade, I found that my > FF card (fujitsu-siemens dvb-c) crashes almost every time when I exit from a > recording playback. It won't tune anymore. Usually OSD still works but > sometimes it also crashes. Only way to recover is to restart VDR and reload > kernel module. I'm using latest fw for ff card. Hi, Same issue here. I was thinking it was an issue with the card, the firmware, the motherboard or pci latency. In the end I stopped using it... I'm even considering giving it to someone else. The only plugins i'm using are xineliboutput and streamdev and I'm able to make it crash by just changing channels. Dish and signal are ok, no errors and my budget and dvb-s2 card are both working perfectly. That's a very good thing i read your message, i'll try to use 1.6.0 and see if it's ok with it :) Cheers. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cDvbDevice::Initialize
Udo Richter writes: Hi ! Thanks for your answer ! > Am 25.09.2010 16:38, schrieb syrius...@no-log.org: >> I'm having a setup with 4 dvb cards, and I'm running 3 vdr instances. >> I'm using an udev rules to make sure adapter numbers don't change. >> I'm using the -D option the assign cards to vdr instances. >> >> I've just discovered that vdr -D 3 would not use the adapter 3 if >> adapter2 was missing from /dev/dvb/. >> >> Here is the patch i'm testing to correct this issue, feel free to >> comment. > > > This would still be wrong if adapter 2 is a dual or more frontend > device, because if adapter 2 has two frontends, then -D 2 and -D 3 refer > to adapter 2 and -D 4 is adapter 3. > > IMHO the -D numbers are a bit outdated anyway, and I would prefer a way > to use /dev/dvb paths directly. Some concept ideas: sure, man page says: -D num, --device=num Use only the given DVB device (num = 0, 1, 2...). There may be several -D options (by default all DVB devices will be used). I was thinking adapter == device. i think you're right, it's kind of outdated. > vdr -D /dev/dvb/adapter0 > - use only adapter 0 agreed, or -D 666 or -D /dev/dvb/adapter666 (l...@usedevice) > vdr -D /dev/dvb/adapter0/frontend1 > - use only frontend 1 of adapter 0 - this could be tricky > > vdr -D /dev/dvb/adapter1 -D /dev/dvb/adapter0 > - Swap ordering of devices i've stopped trying to understand how GetDevice decides... i guess it's outdated as well. > vdr -D /dev/dvb/primary > - follow a symlink primary -> adapter0, like generated by udev > > vdr -D "/dev/dvb/*" > - use all DVB devices > > vdr -D /dev/dvb/primary -D "/dev/dvb/adapter*" > - Use primary first, then use all remaining devices. No duplicates. > > Implementing this needs some API changes, esp. since device plugins can > decide to override the default receiver of VDR, and this interface just > has adapter and frontend number. (dvbsddevice replaces the receive-only > receiver that way.) > > Also, frontend numbers are more than parts of file names. If you swap > frontend 0 and 1 in the file system, VDR cannot receive any more. (been > there, done that.) ok, it's not going to change anytime soon. If we consider a device (man page) == an adapter, am I breaking things down ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] cDvbDevice::Initialize
Hi,
I'm having a setup with 4 dvb cards, and I'm running 3 vdr instances.
I'm using an udev rules to make sure adapter numbers don't change.
I'm using the -D option the assign cards to vdr instances.
I've just discovered that vdr -D 3 would not use the adapter 3 if
adapter2 was missing from /dev/dvb/.
Here is the patch i'm testing to correct this issue, feel free to
comment.
--- dvbdevice.c.orig 2010-09-25 16:29:09.341396415 +0200
+++ dvbdevice.c 2010-09-25 16:25:37.087849316 +0200
@@ -786,29 +786,18 @@
new cDvbSourceParam('C', "DVB-C");
new cDvbSourceParam('S', "DVB-S");
new cDvbSourceParam('T', "DVB-T");
- int Checked = 0;
int Found = 0;
- for (int Adapter = 0; ; Adapter++) {
- for (int Frontend = 0; ; Frontend++) {
- if (Exists(Adapter, Frontend)) {
- if (Checked++ < MAXDVBDEVICES) {
-if (UseDevice(NextCardIndex())) {
- if (Probe(Adapter, Frontend))
- Found++;
- }
-else
- NextCardIndex(1); // skips this one
-}
- }
- else if (Frontend == 0)
- goto LastAdapter;
- else
- goto NextAdapter;
- }
- NextAdapter: ;
- }
-LastAdapter:
- NextCardIndex(MAXDVBDEVICES - Checked); // skips the rest
+ for (int Adapter = 0; Adapter <= MAXDVBDEVICES; Adapter++) {
+ if (UseDevice(NextCardIndex())) {
+for (int Frontend = 0; Exists(Adapter, Frontend); Frontend++) {
+ if (Probe(Adapter, Frontend)) {
+ Found++;
+ }
+}
+ } else {
+NextCardIndex(1); // skips this one
+ }
+ }
if (Found > 0)
isyslog("found %d DVB device%s", Found, Found > 1 ? "s" : "");
else
--
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
"Frank Schmirler" writes: >> The black screen also appears the first time you connect to the >> streamdev-server using HTTP. (its primary output goes black for a >> second then it's ok) > > I have not been able to reproduce this on my machine, except when the server > VDR was not suspended and no idle device was available. Fixed that in > getdevice-0.5.diff. I can't find getdevice-0.5.diff anymore (http://www.vdr-developer.org/mantisbt/view.php?id=582 is broken) I've just tested streamdev 0.5-CVS + suspend.diff from your website. It seems to behave like before. (as described on top of this message) would getdevice-0.5.diff still apply on top of this streamdev version ? Thanks. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
"Frank Schmirler" writes: > On Tue, 27 Jul 2010 15:07:23 +0200, syrius.ml wrote >> Have you had a look at >> http://projects.vdr-developer.org/issues/show/10 ? > > Yep: http://www.linuxtv.org/pipermail/vdr/2010-July/023243.html > Hope Klaus integrates the patch. Hi, I really hope he does too. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
"Frank Schmirler" writes: > On Fri, 30 Jul 2010 15:03:30 +0200, syrius.ml wrote >> Just an offtopic note: i'm using 2 streamdev-client instances, in the >> setup menu i get streamdev-client and streamdev-client2. when I >> change an option from one instance it gets changed in the other's instance >> menu as well. (it's just an ui issue, setup.conf is updated correctly) > > Is your libvdr-streamdev-client2.so a (symbolic or hard) link to > libvdr-streamdev-client.so? Don't do that. It must be a copy. Oh, ok, sorry for the noise then. it was a hardlink. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
"Frank Schmirler" writes: > I have not been able to reproduce this on my machine, except when the server > VDR was not suspended and no idle device was available. Fixed that in > getdevice-0.5.diff. Thanks Frank. Just an offtopic note: i'm using 2 streamdev-client instances, in the setup menu i get streamdev-client and streamdev-client2. when I change an option from one instance it gets changed in the other's instance menu as well. (it's just an ui issue, setup.conf is updated correctly) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
syrius...@no-log.org writes: > "Frank Schmirler" writes: > >> On Tue, 27 Jul 2010 13:26:39 +0200, syrius.ml wrote >>> "Frank Schmirler" writes: >>> >>> [...] >>> > I quickly hacked together a patch at >>> > http://www.vdr-developer.org/mantisbt/view.php?id=582. It's totally >>> > untested, >>> > but maybe you want to give it a try. Might take a while until I have time >>> > to >>> > test it. >>> >>> Hi, >>> >>> The patch applies to the source, it even compiles. but it's unusable >>> because of one unresolved symbol. (tested with the getdevice-0.3.diff >>> patch and a clean vdr source tree) >> >> Uploaded getdevice-0.4.diff which fixes this issue. > > Ok, thanks i'll test that right away. Ok it works as expected for VTP. The black screen also appears the first time you connect to the streamdev-server using HTTP. (its primary output goes black for a second then it's ok) Thanks. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
"Frank Schmirler" writes: > On Tue, 27 Jul 2010 13:26:39 +0200, syrius.ml wrote >> "Frank Schmirler" writes: >> >> [...] >> > I quickly hacked together a patch at >> > http://www.vdr-developer.org/mantisbt/view.php?id=582. It's totally >> > untested, >> > but maybe you want to give it a try. Might take a while until I have time >> > to >> > test it. >> >> Hi, >> >> The patch applies to the source, it even compiles. but it's unusable >> because of one unresolved symbol. (tested with the getdevice-0.3.diff >> patch and a clean vdr source tree) > > Uploaded getdevice-0.4.diff which fixes this issue. Ok, thanks i'll test that right away. Have you had a look at http://projects.vdr-developer.org/issues/show/10 ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
"Frank Schmirler" writes: [...] > I quickly hacked together a patch at > http://www.vdr-developer.org/mantisbt/view.php?id=582. It's totally untested, > but maybe you want to give it a try. Might take a while until I have time to > test it. Hi, The patch applies to the source, it even compiles. but it's unusable because of one unresolved symbol. (tested with the getdevice-0.3.diff patch and a clean vdr source tree) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Help with: vdr-1.7.1 + s2api + h264
Dieter Hametner <[EMAIL PROTECTED]> writes: Hi, >> > I couldn't run properly vdr 171 + s2api + extension patch + s2api patch + >> > h.264patch that's why I keep vdr 170 + s2api patch + h.264patch >> >> There's a git repository for vdr at http://git.gekrumbel.de/?p=vdr.git >> Wouldn't it be appropriate to use it to maintain a working >> vdr+s2+h264 source tree ? > > I'm maintaining that aforementioned git repository. I didn't want to host > different versions of VDR in this git repository (except the 'original > sources' git). Ok, sorry I should have asked you first. BTW is it used by a lot of people ? > This repository is intended to be used as a source for cloning own git > repositories and pulling upcoming development changes provided by Klaus > Schmidinger. If you clone it to a public git hoster (or publish it on some > own server) and add the various patches (s2api, h.264 etc.), it will be easy > for others to retrieve already patched versions of VDR to their local > computers. > > If I get informed of such a repository I will be happy to add a link on my > VDR > git hosting site, to inform others about the patched VDR git existence. > > Look at git homepage http://git.or.cz/ for a list of public git hosting > providers. ok. I'm not a h264 or s2api user yet, it would be very nice if some people could maintain such a repository. It's seem messy to get these patches working and questions about them are very recurrent. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Help with: vdr-1.7.1 + s2api + h264
Goga777 <[EMAIL PROTECTED]> writes: > Hi > > I couldn't run properly vdr 171 + s2api + extension patch + s2api patch + > h.264patch > that's why I keep vdr 170 + s2api patch + h.264patch There's a git repository for vdr at http://git.gekrumbel.de/?p=vdr.git Wouldn't it be appropriate to use it to maintain a working vdr+s2+h264 source tree ? what do you reckon ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Lars Bläser <[EMAIL PROTECTED]> writes: [...] > btw. there is a vdr fork repository (svn://reelbox.org) > reel-multimadia has its own 1.4.7 dvb-s2, h.264 capable vdr > they (Georg Acher?) wrote there own extension för dvb-s2 and they > extended vdr to there needs > it could be interesting to hear of the experience they have made > (backports, using vdr 1.7.x in the future?) I've tried to compile the reelchannelscan plugin without any luck. (did not persevere tho) is it reelly a fork ? I'd be really interested in hearing comments about this version. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Udo Richter <[EMAIL PROTECTED]> writes: > Lets think this through: An open VDR repository for everyone to get in > their personal 'I want this' patches. Surely this will lead to chaos, indeed. > since no one really oversees the needs of all VDR users. (Take > sourcecaps vs. lnbsharing as example.) > So we have to restrict things. Only a few trusted dev's getting write > access. In any case changes that go beyond simple bug fixing would > require discussions about whether things go into the right direction, > and I'm pretty sure that none of the trusted dev's would ever check in > any changes without a previous ack by Klaus anyway. > > So if Klaus ack's anything anyway, why does anyone except Klaus actually > need write access? And what about global warming ? What if germany gets sunny summer weather for the next 24 months ? :) no talk, no commit, nothing for 24 months ? I insist because I'd like to know where things go. I tend to think Klaus won't have as much time as he had in the past. And it's obviously not funny to developp features you're not interested in. So what's vdr future with only one developper ? [snip] > - With a distributed repository system like Mercurical, it would also > easily be possible to do external user branches to support more > cutting-edge features, as long as some other maintainer keeps them up to > date. Think of it as something like the -mm kernels, or as the bigpatch > / extensions-patch. And if things get Klaus' approval, they can be > easily merged back into main VDR too. indeed ! would linuxtv.org be interested in hosting it ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Klaus Schmidinger <[EMAIL PROTECTED]> writes: > On 09/05/08 16:15, Vladimir Kangin wrote: >> We can dedicate server for these purpose. And our administrators would >> be able to support it. Does it make sense? > > Of course I can't prevent people from doing this. > But I won't synchronize my work on some repository where > others call the shots. > It would most likely mean my retirement from VDR development... first of all : RESPECT i'm respectful and thankful for the very nice stable software. but vdr has not evolved for years ! no real new features, it's still meant to be used with one ff dvb-s card. there's a plugin interface but most of the time you don't want to hear about bugs when somebody is using a plugin. what's the point then ? And, what about this blackmail thing ? Wouldn't it be simpler to say "i don't have time anymore, my needs won't evolve and i don't want to code features i won't use, please carry on !" ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
"VDR User" <[EMAIL PROTECTED]> writes: > I will however give you an example. There was a time when the > majority of dvb users I talk to used VDR, and only a few guys used > MythTV. Now the opposite is true. The majority of those people are > using MythTV and few are left who still use VDR. Why? Primarily lack > of support for what's already been previously discussed a million > times.. Lack of support for HDTV, MPEG4, DVB-S2, and a recording > format that is actually usable. The only surprise to me is how many > people burn their recordings to DVD. I don't have any interest in > doing that but clearly a whole lot of other people do. i'm not into dvb-s2 yet. Without talking about this hype technology, what about : - multiple frontend+osd support - complex channel handling (no no not talking about xml, i hate xml) - sourcecap patch (having to patch vdr for such a feature is a no-go for a lot of people) I tend to agree, in the end a lot of people will move to bloat^Wmythtv. (and i agree, a lot of people have stopped using vdr) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
"VDR User" <[EMAIL PROTECTED]> writes: > What ever happened to the idea of setting up VDR deveopment on > mercurial to allow the main contributors who want to work on it to do > so without hassle/delay? I think converting to mpeg-ts instead of > pes, and the hdtv support + all things related would be much farther > along by now! Very good point ! I second this. Nothing prevents you from setting a repository on your side and give access to contributors. Yeah come on, be brave and fork it ! :) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] svn reelchannelscan-0.6.1 for vdr 170
Goga777 <[EMAIL PROTECTED]> writes: > Hi > > Our last discussion about reelchannelscan was in May. > http://www.linuxtv.org/pipermail/vdr/2008-May/017037.html > >>From May in svn version of reelchannelscan there's new features > and fixes. > svn checkout svn://reelbox.org/testing/src/vdr-plugins/src/channelscan-0.6.1 > > Can someone or Vangelis to adopt svn channelscan version for vdr 170 ? sorry to hijack this thread, but is there a version for vdr 1.6 ? I can't get to compile neither channelscan-0.6.0, channelscan-0.6.1 or channelscan-0.6.1.1. don't know if it's related to the latest gcc or anything else. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] FF dvb card and unknown picture type errors
Am I the only one to still have those kind of errors ? In fact I'm not using the output of my ff card and I'm wondering if any hack would allow to transform it into a budget card ? I'm not sure to understand what the dvb tt budget patch does. ( http://linuxtv.org/wiki/index.php/DVB_TT_Budget_Patch ) Would it prevent the card to crash ? (in fact it's the arm that crashes, isn't it ?) My budget card doesn't crash even in case of really bad reception/weather. Is there something i can do to prevent the dvb ff card to crash ? TIA -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
Petri Helin <[EMAIL PROTECTED]> writes: > gimli wrote: >> Screen resolution is 1920x1080 for HDTV. >> When is switch from an SDTV channel to an HDTV channel >> the OSD is way to small. Looks there is no scalling to >> the larger resolution. >> > > You might want to give the cvs a go now. There should be a proper fix in > place and no more reverting is needed. Seems ok. Although, I still have issues with OSD and channels broadcasting "small" video streams (for instance, ITV2 @28.2E => 544x576) In that case OSD is bigger than screen and I miss a bit on the right. The behavior is different whether I use vdr-sxfe or xine-ui With xine-ui OSD is always out of the screen, whatever the video/osd settings. (xine-ui is run in full screen (800x600), setting the aspect ratio or the screen size, using pp/expandi don't change a thing) With vdr-sxfe, I have to set xineliboutput.Video.SwScale to 1 It might be the expected behavior, I don't mind using vdr-sxfe and SwScale. (i just need to resolve some issues with my alsa setup) Thanks. xinelibout settings are: xineliboutput.OSD.AlphaCorrection = 0 xineliboutput.OSD.AlphaCorrectionAbs = 30 xineliboutput.OSD.Downscale = 1 xineliboutput.OSD.ExtSubSize = -1 xineliboutput.OSD.HideMainMenu = 0 xineliboutput.OSD.LayersVisible = 4 xineliboutput.OSD.Prescale = 1 xineliboutput.OSD.Scaling = 1 xineliboutput.OSD.UnscaledAlways = 0 xineliboutput.OSD.UnscaledLowRes = 0 xineliboutput.OSD.UnscaledOpaque = 0 xineliboutput.Video.AspectRatio = 2 xineliboutput.Video.AutoCrop = 0 xineliboutput.Video.AutoCrop.AutoDetect = 1 xineliboutput.Video.AutoCrop.DetectSubs = 1 xineliboutput.Video.AutoCrop.FixedSize = 1 xineliboutput.Video.AutoCrop.SoftStart = 1 xineliboutput.Video.Brightness = -1 xineliboutput.Video.Contrast = -1 xineliboutput.Video.Deinterlace = none xineliboutput.Video.DeinterlaceOptions = method=Linear,cheap_mode=1,pulldown=none,framerate_mode=full,judder_correction=1,use_progressive_frame_flag=1,chroma_filter=0,enabled=1 xineliboutput.Video.HUE = -1 xineliboutput.Video.IBPTrickSpeed = 0 xineliboutput.Video.MaxTrickSpeed = 12 xineliboutput.Video.Overscan = 0 xineliboutput.Video.Saturation = -1 xineliboutput.Video.SwScale = 1 xineliboutput.Video.SwScale.Aspect = 0 xineliboutput.Video.SwScale.Downscale = 0 xineliboutput.Video.SwScale.Height = 576 xineliboutput.Video.SwScale.Resize = 1 xineliboutput.Video.SwScale.Width = 720 -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
[EMAIL PROTECTED] writes: > Don't know, I haven't tried :) > Going to try right now Seems ok now. Thanks again. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
Petri Helin <[EMAIL PROTECTED]> writes: > It will affect in a sense since xine_input_vdr.c is used when building > xineplug_inp_xvdr.so (the xine VDR input plugin) which in turn is used > whether you use vdr-sxfe or xine-ui. So, the important thing is to > replace the xine plugin after recompile, which is done by make install. ok, I was thinking only xine-ui was using the plugin. > Are you saying that you still see the same behaviour when using > vdr-sxfe? Even if you recompile and replace the xine plugin? Don't know, I haven't tried :) Going to try right now -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
Pertti Kosunen <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> but vdr-sxfe wasn't recompiled. it seems there's no dependency to
>> xine_input_vdr.c
>
> You may have to run "make clean-plugins".
what I meant is that it does not seem vdr-sxfe depends on
xine_input_vdr.c
And the modification made to xine_input_vdr.c won't affect vdr-sxfe.
And it can be verified by removing xine_input_vdr.{c,o} vdr-sxfe and
running make vdr-sxfe
--
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
"Simon Baxter" <[EMAIL PROTECTED]> writes:
> If you could share your modified plugin - that'd be great
freevo-vdr.tar.bz2
Description: Binary data
If I recall correctly it was based on freevo-vdr-0.5.
I copy the 2 files in
/usr/local/stow/freevo-1.x/lib/python2.5/site-packages/freevo/plugins/
and I use this in my local_conf.py:
plugin.activate('vdr_interface')
plugin.activate('vdrtv', level=5)
VDR_VIEWER_PLUGIN='sxfe'
#VDR_VIEWER_PLUGIN='xine'
VDR_USE_SVDRP=0
VDR_SVDRP_HOST='telly'
VDR_SVDRP_PORT=2001
VDR_SVDRP_ALWAYSCLOSE=0
#VDR_XINE_FIFO_PATH='xvdr:tcp://telly:37890#nocache;demux:mpeg_block'
VDR_XINE_FIFO_PATH='xvdr://telly:37890'
It's a bit hackish, I haven't taken the time make it clearer and cleaner.
--
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
Petri Helin <[EMAIL PROTECTED]> writes: >>> cvs update -C -r 1.127 xine_input_vdr.c >>> >>> It has been reported to cure the kind of behaviour you have been >>> experiencing. >> >> btw, vdr-sxfe is also affected. >> > > Reverting xine_input_vdr.c, recompiling (make plugins) and reinstalling > vdr-sxfe should fix that. That's exactly what i did. /usr/src/vdr/vdr-1.6.0/PLUGINS/src/xineliboutput $ ls -lht |head -n 6 total 5.8M -rwxrwxr-x 1 laurent laurent 211K May 3 00:04 xineplug_inp_xvdr.so -rw-rw-r-- 1 laurent laurent 249K May 3 00:04 xine_input_vdr.o drwxrwxr-x 2 laurent laurent 48 May 3 00:04 CVS -rw-rw-r-- 1 laurent laurent 187K May 3 00:04 xine_input_vdr.c drwxrwxr-x 3 laurent laurent 4.0K May 1 12:28 po but vdr-sxfe wasn't recompiled. it seems there's no dependency to xine_input_vdr.c -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
Petri Helin <[EMAIL PROTECTED]> writes: > For a temporary solution you could revert file xine_input_vdr.c to > version 1.127: > > cvs update -C -r 1.127 xine_input_vdr.c > > It has been reported to cure the kind of behaviour you have been > experiencing. btw, vdr-sxfe is also affected. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
"Simon Baxter" <[EMAIL PROTECTED]> writes: >> [EMAIL PROTECTED] wrote: >>> Hi, >>> >>> I'm using vdr-1.6 and xineliboutput from cvs. >>> I'm using it with freevo and vdr is controlled through >>> xine-ui/vdr-sxfe by stdin. >>> For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui. > > Can you tell me more on how this works? Are you running a standard freevo > rpm, or built from source? How does the xineliboutput work with freevo, is > there any HOWTO? I'm using freevo-1.x from svn. I'm using debian and ubuntu. I'm installing kaa and freevo in /usr/local/stow and using stow to make it available through the standard paths. (cd /usr/src/kaa; python setup.py install --prefix /usr/local/stow/kaa; cd /usr/local/stow; stow kaa; ldconfig; cd /usr/src/freevo; python setup.py install --prefix /usr/local/stow/free; cd /usr/local/stow; stow free) I then install vdrpylib (although i don't use it) And I use a modified freevo-vdr plugin. (but i can't remember where to get it) > How is this stdin key mapping working? The freevo-vdr plugin catches and maps freevo events to vdr actions that it passes through stdin. (vdr can be controlled through xine when you use vdr or xineliboutput) Sorry my english is not helping this evening. Just run xine --stdctl 'xvdr://url/...#need_stuff' and type 'eventup' (or vdr-sxfe --slave with 'hitk up') Anyway if you're are interested i can give you the modified plugin i'm using. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
Petri Helin <[EMAIL PROTECTED]> writes: > For a temporary solution you could revert file xine_input_vdr.c to > version 1.127: > > cvs update -C -r 1.127 xine_input_vdr.c > > It has been reported to cure the kind of behaviour you have been > experiencing. I'll do that. Cheers. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] cvs xineliboutput
Hi, I'm using vdr-1.6 and xineliboutput from cvs. I'm using it with freevo and vdr is controlled through xine-ui/vdr-sxfe by stdin. For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui. Every so often when i change between channels xine-ui/vdr-sxfe stops displaying video+osd. I have to quit it and start it again. (but commands are still sent to vdr, if i press "up" 2 times while xine-ui/vdr-sxfe has stopped displaying anything, I can see vdr receiving the "up" events) I haven't tried to reverse patches, or to reproduce it without using stdin (--stdctl/--slave). Before I do so, I'm just asking if anybody has encountered this issue already. Cheers. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
Jörg Knitter <[EMAIL PROTECTED]> writes: > Petri Helin wrote: >> [...] >> start up a fluxbox session. The fluxbox session runs a start up script >> which starts vdr-sxfe, which connect to the xineliboutput plugin. >> [...] >> > One general question: Is vdr-sxfe reliable enough on > bad-weather-conditions? I have played around last week with VDR-1.5.18 > and xineliboutputs internal display window, and it was rock-solid while > in the past other solutions like xine or vdr-sxfe crashed if there was a > bigger problem with the signal strength. i also have issues with xine+xineliboutput on bad weather conditions. You could always use a 'while xine "mrl"; do sleep 1; done" or use init/upstart. (not appropriate, i read you need to quit vdr-sxfe to release lirc) > Or do you have implemented some kind of "keep vdr-sxfe > alive"-functionality? Because having to start vdr-sxfe manually again is > IMHO not really set-top-box-like... :) > On the other hand, I would prefer using vdr-sxfe instead of the internal > x11 display because then I can release LIRC by shutting down vdr-sxfe > e.g. if I want to use Elisa as second Media Center for playing back MP3s > and videos in a more comfortable way than VDR can offer... I use freevo 1.x There's a plugin to integrate vdr with it. In that case freevo is the media center for playing video/music/etc... and it launches xine/vdr-sxfe when you want to watch tv. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
Boguslaw Juza <[EMAIL PROTECTED]> writes: > Hi > > Look at http://freevo.sourceforge.net/ - it is the frontend for home > cinema linux PC. It starts Xserver itself, you don't need gdm, gnome > etc... I'm using it and Im very glad :). > I removed freevo TV config and I set xine for VDR as a "external command" > in freevo. It works nice and looks very good. then you should have a look at the vdr plugin for freevo. It adds a new "watch tv" menu entry and forwards key/lirc events to xine. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
"VDR User" <[EMAIL PROTECTED]> writes: > On Sun, Apr 6, 2008 at 9:57 AM, Jean-Claude Repetto <[EMAIL PROTECTED]> wrote: >> I think most VDR users are using a full featured DVB card, so they don't >> need X. > > There are very many users who do not use a full featured card! Please > don't discourage him from finding answers to his questions! I own both, and i would love to swap my ff card for a budget one. At least budget cards don't crash ! :) To go back to the subject, gdm and kdm allow you to autologon an user. The next step would be to run vdr from .xsession for ex. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR developer version 1.5.16 - strange characters
This is the output of my dvb-ttpci FF card: http://img252.imageshack.us/my.php?image=t1yz3.png What are the box around the titles ? Is anybody able to reproduce and fix this ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR developer version 1.5.16 - Makefile
Hi there, First time i'm using the Makefile to install vdr. Why is it : install-i18n: @mkdir -p $(DESTDIR)$(LOCDIR) @(cd $(LOCALEDIR); cp -r --parents * $(DESTDIR)$(LOCDIR)) and install-plugins: plugins @mkdir -p $(DESTDIR)$(PLUGINLIBDIR) @cp --remove-destination $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION) $(DESTDIR)$(PLUGINLIBDIR) with DESTDIR ?= PREFIX ?= /usr/local MANDIR = $(PREFIX)/share/man BINDIR = $(PREFIX)/bin LOCDIR = ./locale being the default ? is there a $(PREFIX) missing after $(DESTDIR) in install-i18n and install-plugins ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Klaus Schmidinger <[EMAIL PROTECTED]> writes: >Should there be a stable version 1.6.0 now, based on what's in >version 1.5.14, but without DVB-S2 or even H.264 support? > > Yes or No? No ! I'm still using 1.4.7. It would have been a yes if : - i was using 1.5 already - new dev version 1.7 was about to be started at the same time and : * if development was about to change so that there will be a (distributed) version control system and more than 1 branch/commiter * if the todo list was known and open * if multiple frontends/display with independant osd+control was in the todo list * if the channel list was about to be revised so that it can handle every specific needs * if config files were about to be in XML ! (nah kidding) *g* NO I WON'T USE MYTHTV ! :-) Cheers -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling Xineliboutput video mode switching
Niko Mikkila <[EMAIL PROTECTED]> writes: >> >> So how do I force Xineliboutput to first scale the _video_ to screen >> >> (not vice versa) and then put OSD (unscaled) on top of that? >> > Same problem here. >> > I'd prefer it to scale the osd the same way vdr-xine does. >> > (i'm using xine as a remote frontend) >> >> There is a setting in /etc/vdr/setup.conf >> (Xineliboutput.VideomodeSwitching = 1), but in Gentoo that file gets I'm already using this setting. For small video resolutions (like on itv1 - 28.2°E - 544x576) osd is bigger and doesn't fit on the screen. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling Xineliboutput video mode switching
Samuli Seppänen <[EMAIL PROTECTED]> writes: > Hi all, > > I have a problem with Xineliboutput's OSD. In low resolution videos it > look doesn't fit the screen. It seems as if Xineliboutput actually > switches the resolution of the (VGA) monitor. > > So how do I force Xineliboutput to first scale the _video_ to screen > (not vice versa) and then put OSD (unscaled) on top of that? Same problem here. I'd prefer it to scale the osd the same way vdr-xine does. (i'm using xine as a remote frontend) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple frontends - [was: HDTV - 2B or not 2B]
Alasdair Campbell <[EMAIL PROTECTED]> writes: > Beside all that, I do believe VDR needs to integrate H264 & HD > recording, along with support built-in for multiple frontends. Hopefully > I can lend a hand with the coding (in about 6 years). I'd be happy to do some clean C++ programming (I've haven't done C/C++ for YEARS). But I don't know where to start. Do you think it would be achievable without breaking everything, or would it need to nearly start from scratch ? (so it would be modular enough to smartly handle every needs) For a start, I would be happy to know if it is something feasible for vdr 1.5. (and how the difficulty would be) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
"VDR User" <[EMAIL PROTECTED]> writes: > Some of us aren't ready to switch just yet but there's no ignoring the > shift in peoples interests. All I can say is when it comes time that > I can't ignore those requirements anymore, I can only hope that VDR > has envolved with the times and I won't be forced to use something > else. Agreed, but in the end I'm pretty sure I will be forced to use something else. (I've been thinking that for a long time and I'm still using it :)) I'm not even sure vdr is modular enough to allow my "requirements" without changing everything, is it ? (When Reinhard says it would be a big patch I guess BIG is meant.) Anyway, there's no public TODO, no public cvs/svn, etc... I'm surprised there's no fork yet. note: this message is not meant to be nasty, disrespectful or provocative in any way. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] next features ? Was: [ANNOUNCE] vdr-xine-0.8.0 plugin
"Graziano Pavone" <[EMAIL PROTECTED]> writes: [...] > And you wouldn't mind applying a huge patch on VDR to achieve this goal? > > This feature is so interesting that I certainly wouldn't mind, even if it > would a very good feature to be included in the 1.5 vdr release... :) imho that's a feature that must be in 1.5 ! as with the smart channel management. utf8 and subtitles are great achievements, what's next ? :-) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
Darren Salt <[EMAIL PROTECTED]> writes: >> - it doesn't require me to recompile libxine > > Neither does vdr-xine (if you're using xine-lib-1.2). oh, good to know, i'll give it a try then. Cheers -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
"mike lewis" <[EMAIL PROTECTED]> writes: Hi, > I've used vdr-xine, and I've used xinelibout for vdr. I've just ogt a > general question, as they both seem to have similar functionality (or > at least they both satisfy my need for a software client head to vdr. > What's the driver for vdr-xine? I've heard people say xinelibout is > "better" because it is more stable. But, whats the reality? If you've used both you should be able to compare them, shouldn't you ? I've also used both. Now i'm only using xineliboutput because (just facts, no attack !) - it has support for network without patching for longer - it doesn't require me to recompile libxine - network features are more advanced - i can have more that one frontend watching/sharing the same channel. - now i just aptitude install libxine1-xvdr to install the client side. Obviously the two plugins are both great plugins. And, Reinhard you do a really good job providing patches for vdr & xine ! Thanks a lot. I guess the hidden question was "have you ever considered to merge the two projects ?", wasn't it ? :) My question would be: "one vdr, one xineliboutput plugin, 2 dvb cards, 2 independant frontends displaying different channels(+osd and stuff) without streamdev, has it been considered ?" :) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Not good behaviour from vdr
Ludwig Nussel <[EMAIL PROTECTED]> writes: >> [...] > I wonder whether reloading modules is still an appropriate action. > Nowadays it's possible for example to bind/unbind drivers to/from > specific devices. Ie if you have multiple dvb-ttpci cards it should > be possible to reset a specific one. Maybe it would even be possible > to implement some kind of reset ioctl in the kernel drivers so vdr > doesn't need to rely on external scripts at all. Oh, that would be wonderful ! It's only my ff card that crashes. I'm running vdr inside a domU (unfortunatly atm it's running 2.6.18). And after a while the firmware doesn't get loaded anymore => "saa7146_vv: saa7146_vv_init(): out of memory. aborting." (iirc, it's an old bug resolved in recent kernels) By the way, does the budget patch fix the crashing of FF cards ? (I know it's not a fix, since i'm only using software decoders i might consider the modification if it prevents the ff from crashing) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev and subtitles and HD
[EMAIL PROTECTED] writes: > Ok, Thanks a lot for this very quick patch. > > Unfortunatly it doesn't solve the issues i have with vtp. > I'll have a look at the bug tracker to see if it has already been > reported. Hm in fact the issues I have are with vdr 1.5.1 and VTP. I went back to 1.4 and vtp seems quite stable. thanks again. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev and subtitles and HD
Petri Hintukainen <[EMAIL PROTECTED]> writes: > On Tue, 2007-04-03 at 15:20 +0200, [EMAIL PROTECTED] wrote: >> Petri Hintukainen <[EMAIL PROTECTED]> writes: >> >> Hmm what about section filtering ? >> it seems section_filters-0.2.patch doesn't apply well on cvs version. >> is it possible to have both ? >> > > I generated new patch against current CVS (section_filters-0.3.patch). > > It includes also HTTP TS PAT/PMT patch (it was quite impossible to > create separate patches without collisions). Ok, Thanks a lot for this very quick patch. Unfortunatly it doesn't solve the issues i have with vtp. I'll have a look at the bug tracker to see if it has already been reported. Cheers -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev and subtitles and HD
Petri Hintukainen <[EMAIL PROTECTED]> writes: >> And are there any plans for streamdev to support HDTV (h.264 or >> similar)? > > It should be possible to watch H.264 HDTV using HTTP TS streaming with > the patch from > http://phivdr.dyndns.org/vdr/vdr-streamdev-patches/testing/ Hmm what about section filtering ? it seems section_filters-0.2.patch doesn't apply well on cvs version. is it possible to have both ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev client & server contention
"Simon Baxter" <[EMAIL PROTECTED]> writes: > I've been trying all the available modes in the streamdev-server to > find the one that suits my needs best. > > I have 2 VDRs, a server and a client. Ideally, I'd like them both to > be able to change channel - and when the transponders need to change, > one will just force the other to change as well. This is sort of > possible with the"Client may suspend" set to "offer", but has some > problems. Do you really need two vdr running ? Would vdr-xineliboutput help ? You could have several frontends watching the same channel. (and every frontent can change the channel) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput Version 1.0.0pre6
- Fixed unscaled OSD scaling to display size when low-resolution video or different aspect ratio unfortunatly it seems it's not fixed here. and i am still having big sound/video glitches/issues when zapping. i'm using xine-lib 1.1.2 and xine-ui 0.99.4+cvs20060813-1 and tcp it's reproducible on ITV1 (S28.2E) hm and transparency doesn't work on this channel with vdr-sxfe. Sorry if i'm not giving a enough informations, What should i do ? - revert libxine to 1.1.1 ? - patch libxine 1.1.2 with some patches ? - revert xineliboutput plugin to something older ? - move back to vdr-xine + network patch ? what's the best setup atm ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-xineliboutput-1.0.0pre5 issues
Hi, Am I the only one to have those issues ? - no audio / big audio lags when changing channels (also the case with pre4) - osd does not fit screen. (right part is outside the screen) i'm using xine-ui with remote tcp stream and debian/unstable: libxine is 1.1.2-6 xine-ui is 0.99.4+cvs20060813-1 vdr-1.4.3 it also happens with vdr-sxfe. but the osd is too small. it doesn't use all the screen... -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recording priority question
Anssi Hannula <[EMAIL PROTECTED]> writes:
>> [...]
> For a reference, here's the algorithm VDR 1.4.2 uses to select the
> device for viewing and recordings:
> If this is liveview and the primary device provides the channel without
> interrupting anything else, it is used. Otherwise:
> Devices that have higher priority receivers on other transponders than
> this recording will not be considered.
> For other devices, checks are done in this order (the first ones are
> valued the most):
> 1. If the card is already recording on the same transponder, use that
> device.
> 2. Avoid the card if it has an ongoing recording.
> 3. Avoid the card if it is used for transfer-mode receiving.
> 4. Use the device which has the lowest priority recording already running.
> 5. Use the device which has the lowest number of CAMs.
> 6. Avoid primary device.
> 7. Avoid full-featured cards.
is it possible to give different priorities to transfer modes ?
i'm using xineliboutput for liveview
streamdev vtp for 2nd liveview ( would several liveviews be handled in
vdr 1.5 ? :) )
i'm using a script to manually get epg (something that reads from
streamdev http) and i like this to have priority over vtp but not over
xineliboutput. (and for sure recordings still have the higher
priority)
is it possible to change the priority in the plugin sources ?
(i'm still not understanding everything about Receiver, Device and
{p,P}riority, any advice where to start ?)
for example, i'd like xineliboutput to set a higher priority to the
receiver (is it the good term ?) when a xine client is connected.
so that transfer_mode-liveview with xinelibout gets handled in a
better way
does it make sense ?
is vdr actually ready for that kind of things ?
--
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: other rtp clients ?
Udo Richter <[EMAIL PROTECTED]> writes: > I've tried, and was successful with udp://@224.0.1.9:37890 oh yes, i don't know what i did before asking here, but now it's working. > This is a multicast transmission, so the IP network will take care of > connecting the client to the server. No need to specify any local IP > address. > You may need to initialize the connection with one of the remote > clients first. Also, see option Remote Clients-> Transmit always on - > which seems to be buggy though. Thanks -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput: other rtp clients ?
Hi, I'm the happy user of xineliboutput 1.0.0pre3. I'd like to know if it's possible for other rtp clients to play the multicast stream. (while xine+xineliboutput is playing it) In fact i'd like to be able to use vlc to transcode/re-stream it. what's the format of the video stream sent by xinelibout ? is it something vlc can read directly ? Or how hard would it be to give vlc the ability to play this stream ? Any idea ? Thanks in advance. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] epg scan of a specific transponder
Udo Richter <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> Is there a plugin that allow to scan a specific transponder ? > > Hmm, usually its enough to tune to that transponder, I think. So if > you start a recording, or use streamdev to enforce this transponder on > the second card, epg data should be updated. yes i'm considering using streamdev, and something like 'curl -m $maxtime -o /dev/null url'. > With a single satellite, the automatic epg background scan has a > round-trip time of 20 minutes or so. Is this really not enough to keep > your epg up to date? most of the time we're tuned to a bbc or itv channel. I'd like to use master-time to automatically records my soap shows even if i'm in front of the tv. Main problem is that itv & bbc only broadcast now/next epg and i have to tune to one channel of the transponders regularly. (i could also import external epg into vdr) Cheers -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] epg scan of a specific transponder
Hi, Is there a plugin that allow to scan a specific transponder ? I know it's possible to trigger a full scan, but i would like to know if it's possible to only checks some transponders (not all). I guess an option to the svdrp SCAN command would be nice :) In fact while i'm watching a channel (using transfer mode) (using dvb card #1) i'd like to trigger the retrieval of epg of another channel (using card #2) Hmm, in a multiple dvb cards setup, using svdrp: would it be easy to: - list the dvb card and their actual use ? (freq/channel/etc... recording/watching/transfer mode ... etc) - select the card when using the SCAN command ? yes i know, i'm still hoping to use my dvb cards in a way vdr has not been developped for :) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
