Re: [vdr] vdr suggestions & osd colour oddity

Chris Elsworth wrote: When viewing a channel, pressing Up/Down currently changes channel; would it be possible to allow these buttons to just show channel information (with now/next in) for the previous/next channels, allowing one to quickly view what is on the other channels? Why don't you us

Re: [vdr] [ANNOUNCE] VDR maintenance patch 1.4.1-3

e9hack wrote: after applying the patch, I get many entries (30 per second) in the syslog: Aug 6 23:20:23 very-new-darkstar vdr: [11415] ERROR (svdrp.c,84): Address already in use The svdrp server port (default 2001) is in use by another program, in other words, there's another VDR instance

Re: [vdr] next developper version

VDR User wrote: Klaus, any particular reason you're not releasing the TODO list? Probably to keep expectations down. If feature X is on the todo list, then it might be implemented next week. Or next month. Or next year. Or in 5 years. Or never. But people will for sure ask every week 'when wi

Re: [vdr] RFC: Man page intstallation support for plugins?

Klaus Schmidinger wrote: install-doc-plugins: @for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do $(MAKE) -C "$(PLUGINDIR)/src/$$i" install-doc; done I wouldn't mind having that. However, what if a plugin's Makefile doesn't provide an 'install-doc' target? You might want to make

Re: [vdr] Making a cList object thread safe?

Christian Wieninger wrote: Thanks! So the following should work (please correct me if I'm wrong): I add a cMutex object in the cList derived class and 2 functions: class cThreadSafecList: public cList<...> { ... private: cMutex mutex; public: void Lock(void) { mutex.Lock(); } void Unloc

Re: [vdr] Re: VDR prefers my CI DVB device for recordings and blocks it unnecessarily

Klaus Schmidinger wrote: @Martin: any news on this? With recent drivers and firmware it should be possible to record and watch even the high-bandwidth channels like ZDF on a FF card. Question is, how recent. I'm just running a recording on ARD. vdr-1.4.1-5, DVB driver of kernel 2.6.16.19, late

Re: [vdr] Re: VDR prefers my CI DVB device for recordings and blocks it unnecessarily

Klaus Schmidinger wrote: Udo Richter wrote: Lots of transfer buffer overflows and sluggish OSD, because VDR used the primary FF card for recording, while the secondary budget card is idle. System is back to normal if I switch to another channel. Just tested it by recording ARD from the

Re: [vdr] Re: VDR prefers my CI DVB device for recordings and blocks it unnecessarily

Anssi Hannula wrote: Consider this scenario: - user watches channel 1, transponder 1, via FF - recording starts for channel 1, transponder 1, via FF add here: - live view is interrupted as FF switches to transfer mode - recording starts for channel 2, transponder 2, via budget The primary d

Re: [vdr] Re: VDR prefers my CI DVB device for recordings and blocks it unnecessarily

Jörn Reder wrote: Hmm, it's not that easy because it ignores the original intention of this thread. Not really. The side effect that osdteletext will force recordings on the FF card on the same transponder was caused by the change in 1.4.1-2, that was some time before your post. Its going bac

Re: [vdr] Sudden vdr restarts almost continuously

Jukka Palko wrote: I have been running vdr 1.4 version with rather good success for some time now, but now all of a sudden I have started getting almost continuous restarting of vdr. Aug 23 09:31:11 sempron vdr: [16318] ERROR: video data stream broken Cards in machine are: # lspci -v -s 0a.0

Re: [vdr] Sudden vdr restarts almost continuously

Jukka Palko wrote: I doublechecked things on the host a while back and looks like the cause is clock adjustment. :) After disabling the adjustment from transmissions, the continuous restarting ended. Propably ain't got the priviledges set up properly. ;) Aug 23 10:00:32 sempron vdr: [19692] S

Re: [vdr] Re: VDR prefers my CI DVB device for recordings and blocks it unnecessarily

Klaus Schmidinger wrote: So how shall we distinguish between cReceivers that do actual recordings and such that just receive, e.g., teletext data? Or those that receive a radio channel for streaming it to a remote client? Where's the limit? Is there a way to predict whether receiving a channel

Re: [vdr] epg scan of a specific transponder

[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. With a single satellit

Re: [vdr] xineliboutput: other rtp clients ?

[EMAIL PROTECTED] wrote: 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. I've tried, and was successfu

Re: [vdr] *** glibc detected *** double free or corruption 1.4.2-1 Patch

Hans-Werner Hilse wrote: There had been a "free(aux);" added in that patch in timers.c in the assignment operator ("=") function. Probably it didn't took an earlier (conditional?) free() into account and such rans into a glibc-assertion. This seems to be at least one source of bugs. I've detect

Re: [vdr] *** glibc detected *** double free or corruption 1.4.2-1 Patch

Udo Richter wrote: ==4652== Invalid free() / delete / delete[] ==4652==at 0x1B904B04: free (vg_replace_malloc.c:152) ==4652==by 0x8103F5F: cTimer::operator=(cTimer const&) (timers.c:108) ==4652==by 0x80FE349: cSVDRP::CmdMODT(char const*) (svdrp.c:1136) ==4652==by 0x810

Re: [vdr] *** glibc detected *** double free or corruption 1.4.2-1 Patch

Klaus Schmidinger wrote: It's probably best to implement an actual copy-constructor. Please try the attached patch, which contains both changes. Attached is the correct version. Thats the better fix of course, and may fix this in case some plugin did the same mistake. (couldn't find one in

Re: AW: [vdr] *** glibc detected *** double free or corruption 1.4.2-1 Patch

martin wrote: just to let you know: the patch you attached here, did not solve the problem! My VDR crashed again. Just a few minutes too late... The patch had another bug that re-introduced the original problem once again. The new copy constructor did not initialize the aux pointer, and the

Re: AW: [vdr] *** glibc detected *** double free or corruption 1.4.2-1 Patch

Klaus Schmidinger wrote: That'll teach me not to write code when I'm on my way out to the "Biergarten"... ;-) Next time, do it afterwards. Afterwards, code is much more 'fluently'. ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linu

Re: AW: [vdr] execute command after vdr starts

C.Y.M wrote: Thanks for your replay, but I was looking for a switch that would make vdr run a script right after vdr starts up. If you want to start a program together with VDR, why don't you put it into your runvdr script? Cheers, Udo ___ vdr

Re: AW: [vdr] execute command after vdr starts

C.Y.M wrote: Because in the runvdr script, the vdr command is executed by an "eval" statement which basically waits for the process to die before it continues on. This could be avoided by backgrounding VDR, do other stuff, and then 'wait' for VDR to terminante. 'wait $PID' will even return the

Re: AW: [vdr] execute command after vdr starts

C.Y.M wrote: Yes, I like the idea of backgrounding VDR using "&" and then using 'wait $PID'. Is that the method you use? I've been trying to find the best way to do this. Could you give me an example? :) Something like that. This is a snippet of my overgrown runvdr script: # Run VDR eva

Re: [vdr] *** glibc detected *** double free or corruption 1.4.2-1 Patch

Hans-Werner Hilse wrote: bug... The free() *does* hurt, however. The standard tells us not to free a pointer twice (in fact, the man page suggests that "undefined behaviour occurs"). That's why there is this "double free assertion", I think. But what my solution suggested was just a circumvention

Re: [vdr] [ANNOUNCE] vdr-femon-1.1.0 & vdr-skinsoppalusikka-1.0.2

Dominique Simon wrote: - Added --remove-destination to the 'cp' command in Makefile. LinVDR's Busybox can't handle that option. What is it good for? This matches equal changes in recent VDR Makefiles. From VDR-1.4.1-5: - Added --remove-destination to the 'cp' command for binaries in the Makef

Re: [vdr] recording sequenced movies

IT wrote: I have 2 cards in my vdr system. When I want to record sequenced movies from one channel, 2 different records are started and both cards are blocked. I'm not sure what exactly you mean with sequenced movies, but I guess its about two overlapping timers on one channel. In case of over

[vdr] [RFE] Soft-cancel cThread

Hi, I have a suggestion for a VDR change: I could use a way to end a cThread externally without having to wait and without hard canceling it. My thread runs with the usual while (Running()) loop. To signal the loop to stop, it would be enough to set running=false. However, running is a priva

Re: [vdr] [RFE] Soft-cancel cThread

Klaus Schmidinger wrote: There are two ways this could be done. First, by adding a function SoftCancel() { running=false; }. Or second, by modifying Cancel() to just set running=false if called with Cancel(-1) or Cancel(0,false) or similar. I would prefer using -1 as a special value for this,

Re: [vdr] [RFE] Soft-cancel cThread

Klaus Schmidinger wrote: I guess you'll also want me to increase the API version number if this goes into version 1.4.4? There's no urgent need from my point, nothing that will be publically available any time soon (if at all), and nothing that should break because of that. And the next APIVE

Re: [vdr] News story: Fox TV tries fixed image ads

Harald Milz wrote: German Netzeitung writes on http://www.netzeitung.de/internet/443044.html that Fox TV tries to force ads even in digital recordings by using fixed images. According to the story, you can't skip or cut fixed images. What kind of nonsense are they writing? Found this English a

Re: [vdr] Control Plugin and Keys F1 - F12

Rene Bartsch wrote: But the remote plugin doesn't have OSD, does it? It has. Its a really good replacement for the buggy control plugin. The only thing I miss is the possibility to end a session with Ctrl+C, you have to terminate the telnet program side. Cheers, Udo __

Re: [vdr] Re: vdr-1.4.3 + softdevice no video out!

Paul ZHU wrote: my question is why it try "tp 112581",not "tp 12581", because from /video/channel.conf, it gives "12581". Nothing unusual, VDR just encodes the polarization internally that way. 10 is horizontally, 20 is vertically. Cheers, Udo _

Re: [vdr] empty spaces in channels list

Boguslaw Juza wrote: I have got big request for Author - It would be nice to make "spaces" in channels list. I want to set "info channels" from 1 to 8, "movie channels" form 10 to 15, sport from 20 etc... So I need to make empty spaces witch ch. numbers 9, 16-19... etc. Switching channels Up/Do

[vdr] [ANNOUNCE] runvdr extreme

Hi list, I've released the first release of my runvdr-extreme package. runvdr extreme is a runvdr script, just like the runvdr script included in the VDR distribution. Additionally, it supports configuration files, lots of command line options and additional features. -> http://www.richter-u

Re: [vdr] [ANNOUNCE] runvdr extreme

Peter Bieringer wrote: Thank you for the nice script. One fix is necessary: -[ -n "$VFAT" ] && VDRCMD="$VDRCMD -v" +[ -n "$VFAT" ] && VDRCMD="$VDRCMD --vfat" Hmm, you're right. Thanks. I've missed that because my VDR is switched to vfat on build time. I found only one m

Re: [vdr] Re: [ANNOUNCE] runvdr extreme

Suur Karu wrote: Nice script, but one question. After starting 'runvdr&' file with name '-' is created with content: /bin/setterm For what is it? For checking if people would notice. ;) Note to myself: Don't do these last-minute changes Attached patch should fix this. Cheers, Udo Inde

Re: [vdr] [ANNOUNCE] runvdr extreme

C.Y.M wrote: I'm using something like this: eval "screen -D -m -S vdr $VDRCMD &" This should work: WRAPPER="screen -D -m -S vdr" Or this: runvdr --wrapper="screen -D -m -S vdr" Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxt

Re: [vdr] Re: [ANNOUNCE] VDRAdmin-AM-3.4.7

Andreas Mair wrote: that's a known issue with Internet Explorer. I don't know how to fix this correctly. Other browsers (FireFox, Opera, Konqueror) do fine. You can take a look at contrib/user.css_example to find a workaround or use another browser ;) Thats one of the flaws of the IE layout en

Re: [vdr] vdr-1.4 and osdpip anyone?

Harald Milz wrote: I'm trying to compile osdpip-0.0.8 in vdr-1.4.1, and I get osd_info.c:233: error: ‘cDevice’ has not been declared Anybody managed to port it to 1.4? 0.0.8 is from May 2005... osdpip requires a patch since 1.3.31. See wiki: http://www.vdr-wiki.de/wiki/index.php/Osdpip-plug

Re: [vdr] VDR deletes directories

Reinhard Walter Buchner wrote: I have the same problem (still using an older version of VDR, tho). VDR does delete the contents of the directory, but it doesn't always delete the primary directory below 'video'. In your example you (or in my case me ;o)) still have /video/nano/Die_Welt_von_morge

Re: [vdr] vdr-1.4 and osdpip anyone?

Harald Milz wrote: But it still cries for help: receiver.h:32: error: extra qualification ‘cOsdPipReceiver::’ on member ‘cOsdPipReceiver’ make[1]: *** [osd.o] Fehler 1 This is a GCC-4.x error, already mentioned in the 0.0.8 release thread on vdr-portal. Just delete the cOsdPipReceiver:: par

Re: AW: AW: [vdr] Problem with audio sync in playback - maybe caused by ntpd stepping local clock?

martin wrote: So, as far as i can read with my basic knowledge: if there is a difference of more then 2 (don't know the unit, but I think it must be seconds), there is a step in time. If SAT time and internal clock differ by more than 2 seconds, and this time offset is reported twice in a row,

Re: [vdr] FF card A/V sync suggestion

Tero Siironen wrote: However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these. I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade into black, the data st

Re: [vdr] FF card A/V sync suggestion

C.Y.M wrote: Utilizing mpegpes is really the best of both worlds. We would still be using the video output on the FF card but having software to process the actual mpeg decoding. There would be no transcoding involved because obviously the recording would already be in a DVB resolution format.

Re: [vdr] FF card A/V sync suggestion

C.Y.M wrote: If the answer to this question could be discovered, then problem solved. So, what you are suggesting is VDR is not doing something that mplayer is doing that fixes the problem. Hmm... so then it is not a driver or firmware issue after all?? Could we agree that much? :) I wou

Re: [vdr] FF card A/V sync suggestion

Pasi Juppo wrote: How come you make the conclusion that this is limited to one specific channel? To my understanding there are multiple channels where this problem occurs. Just talking about the case that I've reported. I experience such issues only very rarely, and mostly related to bad recep

Re: [vdr] Can xineliboutput and dxr3 coexist?

Glyn Edwards wrote: I've got VDR (1.4.3) running on a machine by my TV and have just been playing with the xineliboutput plugin to stream vdr over the network. Everything works well on its own but I'd like to be able to have someone watching TV on one channel via the dxr3 and someone else watchin

Re: [vdr] FF card A/V sync suggestion

C.Y.M wrote: mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr Notice that "-framedrop" is added to the command line. I wonder if that is the reason why mplayer is "immune" to the a/v desync problem. Definitely not just that. My playback issue already disap

Re: [vdr] FF card A/V sync suggestion

Morfsta wrote: Certainly I think the problem is that VDR is not properly doing sync, In a way, I agree. VDR does not sync at all. Never. Simplified, here's what the VDR playback really does: - Read data from file in frame-sized chunks into read buffers - If the DVB driver accepts data, read a

Re: [vdr] FF card A/V sync suggestion

Tero Siironen wrote: Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X I've checked your recording. Lost "The other 48 days" - surely one of the worst episodes for me

Re: [vdr] FF card A/V sync suggestion

C.Y.M wrote: IRL, time is constant. But on playback if vdr doesn't clock its data, then desync is quite possible. For example, if there's nothing to "change" for a few video frames, because they're using "stack" compression they won't send an empty frame. So, consider this blackout time in "Lost"

Re: [vdr] FF card A/V sync suggestion

Klaus Schmidinger wrote: Morfsta wrote: I second that, please don't let it drop again.. Is anyone actually working on this, Klaus, Oliver, ANYONE? I'm not working on this, because ATM I wouldn't know what to do. Any comments on C.Y.M's point that PCR should be recorded/used? -> http://www.li

Re: [vdr] FF card A/V sync suggestion

Udo Richter wrote: Tero Siironen wrote: Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X Demultiplexing with ProjectX throws 11649 of errors like this: !> error

Re: [vdr] SVDRP connection freezes

Tony Houghton wrote: The problem is that the svdrp connection has a tendency to freeze. I have to wait a few minutes for the socket to timeout at the system level. VDR's SVDRP timeout is set to 0, but I don't think that's making a difference. I think the reason other programs such as vdradmin wor

Re: [vdr] SVDRP connection freezes

Tony Houghton wrote: If you want to rely on existing stuff, maybe you can use the remote plugin from Oliver Endriss for your needs - it supports tty control and telnet control. That sounds like the best idea. If I wrote my own plugin I'd probably just be effectively duplicating the telnet inte

Re: [vdr] FF card A/V sync suggestion

Oliver Endriss wrote: Does mplayer really play PES data 'as is'? Afaik it recodes data to MPEG-1.(?) From CPU load on my machine, mplayer cannot do much with the signal. The CPU load is even lower than the VDR load when playing back 001.vdr. And even decoding in sotware would out-run my machi

Re: [vdr] SVDRP connection freezes

Tony Houghton wrote: [When playing a recording] I've since noticed that when SVDRP freezes while the progress bar is on screen the clock of the current time shown under the bar stops counting, although playback continues. Perhaps the OSD is freezing as well as SVDRP? Its possible that the VDR

Re: [vdr] FF card A/V sync suggestion

whoMAN wrote: mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime. Not too efficient, but since transcoding to MPEG 1 takes little resources, most people

Re: [vdr] xineliboutput letterbox & mplayer problems

Simon Baxter wrote: If I start the plugin with : vdr -P"xineliboutput --local=sxfe --video=xv --audio=alsa --remote=none" I get a letterbox window in the middle of the gnome screen. So I tried: -P'xineliboutput --fullscreen --local=sxfe --video=xxmc --audio=alsa --remote=none' This gives me

Re: [vdr] FF card A/V sync suggestion

Petri Hintukainen wrote: xine and/or mplayer just re-generates the pes layer. So, it have to be there ? xine has no problems with the provided samples, so I guess it must be in the PES layer re-muxing. Has anyone with the problem tried to replay with separate mpa+mpv -> pes streams ? For the te

Re: [vdr] FF card A/V sync suggestion

Udo Richter wrote: Udo Richter wrote: Tero Siironen wrote: Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X The only disturbance I've noticed is a slight jitt

Re: [vdr] FF card A/V sync suggestion

VDR User wrote: about this... Copy the mplayer code that does the PES layer and slap it into vdr just to test if the problem persists? I don't think that it is that easy. Its just educated guessing, but I assume that the mpeg data is going a long way through the mplayer core, through demult

Re: [vdr] vdr shutdown handling / streamdev plugin

Jörg Wendel wrote: a question about the 'new' vdr shutdown handling implemented a few versions ago. [..] But why vdr call this so often, isn't it only required if the vdr is going to shutdown? Even without the log message, at first view it looks like unnecessary load? VDR calls this function t

Re: [vdr] vdr shutdown handling / streamdev plugin

Jörg Wendel wrote: For plugin developers, I suggest to keep it simple in there. Its probably a good idea to tr() the string just once and cache it afterwards. this would be a nice change in the streamdev plugin. The attached patch does it. This patch has one side effect: The message wont be r

Re: [vdr] pvrinput multiple cards, recording and epg

Simon Baxter wrote: I'm trying to get my PAL PVR-500 working in a non-PAL country. May sound weird, but I'm preparing to move back to New Zealand. Correct me if I'm wrong, but isn't NZ a PAL country? At least from what I know the Australian area is mostly using PAL. Cheers, Udo __

Re: [vdr] how to save the setup.conf

BRUNETON Béranger wrote: Is there a way, from a plugin, to save immediately the setup.conf instead of waiting a proper VDR shutdown? I a word how to call Setup.Save() from a plugin method ? Calling Setup.Save() should be fine, unless you do it from a background thread. VDR does call it too fo

Re: [vdr] [ANNOUNCE] vdr-osdserver 0.0.1

Hi list, the attached patch fixes compile issues with pre-4.x GCC compilers. Cheers, Udo Index: osdobjects.h === --- osdobjects.h(Revision 812) +++ osdobjects.h(Arbeitskopie) @@ -214,6 +214,7 @@ virtual eO

[vdr] Segfault if cSkinDisplayMessage is replaced by another display object

Hi Klaus, I've isolated an null pointer dereferencing bug in cSkins::Message(): In the very rare case that a message is displayed using a cSkinDisplayMessage object, and the message is not removed before another cSkinDisplay object takes control, the next attempt to display a message while n

Re: [vdr] vdr shutdown handling / streamdev plugin

Klaus Schmidinger wrote: For VDR, the two if's in the inactivity shutdown should be swappable with no serious side effects, see attached diff. All the calls do noting important, except the cCutter::Active() call, and this one is called often enough in other situations. But even with this patch,

Re: [vdr] vdr shutdown handling / streamdev plugin

Klaus Schmidinger wrote: Are you sure? ACTIVITYTIMEOUT is 60 seconds, so wouldn't your change just avoid the calls until 60 seconds after the last user activity? Hmm, you're right. Its not a test on Setup.MinUserInactivity * 60. My patch would just avoid these calls the usual 60 seconds after

Re: [vdr] vdr shutdown handling / streamdev plugin

Klaus Schmidinger wrote: The attached patch makes it call cPluginManager::Active() only if it really wants to shut down, and if there is actually an option for plugins to delay the shutdown (i.e. this is not a forced shutdown). If cPluginManager::Active() returns 'true' once, it waits for SHUTDO

Re: [vdr] vdr shutdown handling / streamdev plugin

Klaus Schmidinger wrote: I agree to move it down until before the line if (timer && Delta < Setup.MinEventTimeout * 60 && ForceShutdown) { in order to not interfere with the "assuming manual start of VDR" stuff. But if we move it further down, the dsyslog("reboot at %s", *TimeToString(Next)

Re: [vdr] Re: Problem with vdr-1.4.4-1 and extrecmenu

Klaus Schmidinger wrote: Add the line #define uint64 uint64_t to VDR/tools.h. I'll add this in the next maintenance patch, too. In the long run all plugins should change this to uint64_t, though. better, re-add it as typedef as it was before. Attached. Cheers, Udo --- tools.h.orig

Re: [vdr] Re: Problem with vdr-1.4.4-1 and extrecmenu

Klaus Schmidinger wrote: Matthias Schwarzott wrote: Why not just keep it away. I think it is not too hard to replace that in the plugins. You're probably right. By the time I'll release the next maintenance patch I guess all plugins will have been updated, anyway. This strikes on the control

Re: [vdr] Segfault if cSkinDisplayMessage is replaced by another display object

Udo Richter wrote: The attached patch changes cSkins::Message() by only checking the existence of cSkinDisplay::Current(). If no current cSkinDisplay exists, any old displayMessage object is deleted and a new one is created. I've found another segfault related to displayMessage. If VDR

Re: [vdr] pid change, timers and an after-skript

Janne Liimatainen wrote: when recording a program with a tailtime of eg. 5 minutes there is often a pid change when the show actually ends, which causes the recording to stop and then restart again for a few minutes. And when using a script that automatically processes recordings after they are

Re: [vdr] Parameter --manual-start/--timer-start

Marko Mäkelä wrote: I have written a patch for making the Power key suspend the output. Some softdevice users have found it useful, but I've been told that the patch does not stop playback on full-featured cards. You can access the patch here: http://www.iki.fi/~msmakela/software/vdr/#suspend I

Re: [vdr] [vdr bug]Shutdown during an active timer is broken

Thiemo wrote: So here is my solution: - if a recording is running and User presses "Power" tell him the box will shutdown after the current recording - If he presses "Power" a second time, ask if he realy wants to do this (like before) *and* stop any running recordings (i reused the code from U

Re: [vdr] [vdr bug]Shutdown during an active timer is broken

Thiemo wrote: Plus, effectively, while you currently confirm shutdown with "power, ok", you now confirm with "power, power". And together with the other numerous reasons for not shutting down, this gets confusing: Use power button to override running timers, and use ok button to override timers

Re: [vdr] Best DVB-S card

Glyn Edwards wrote: > I've been looking at the Nexus-S because it is fully featured and I > don't > have any spare PCI slots left. With a FF card I could remove the DXR3. All FF cards are basically cards made by Technotrend, and in my opinion it doesn't make any difference whether the card h

Re: [vdr] How to detect if a timer was deleted?

Christian Wieninger wrote: for a new feature of epgsearch, I'd like to do a continuous check (in a separate thread) if any timer was deleted via OSD or SVDRP since the last check. The only thing I found so far is to build a timer array and compare it at each check with the current timer list. Bu

[vdr] [RFC] Shutdown rewrite for 1.5.x

Hi list, The program code for automatic and manual shut down and for automatic restarts for timer recordings is in VDR 1.4.x very complex and error-prone, and behaves strange in some situations. With Klaus' permission I am working on a re-implementation for the upcoming 1.5.x developer builds

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Reinhard Nissl wrote: Further feature request: At least on single card systems it would be nice to have VDR wakeup e. g. at 03:01 to do just an EPG scan and shutdown afterwards. This opens up the discussion about whether VDR should handle external tasks together with timers. I think that VDR s

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[EMAIL PROTECTED] wrote: How about taking epgsearch's behavior and put up a message 'VDR is waiting for background tasks to complete. Press "ok" for details'. Pressing "ok" would bring up an osd list containing all plugins, which didn't return null in their Active()-method, with their todo-Text.

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Reinhard Nissl wrote: Ok for a start (and to test the new implementation), scheduling the automated EPG scan could be implemented by a plugin. Plugins cannot modify the restart time currently, doing this as a plugin would require the complete shutdown mechanism to be re-implemented in the pl

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Christian Wieninger wrote: perhaps this is too trivial, but why not create a daily or whatever timer as you suggested before with a special name like '@epgscan' and react on that? This would be a dirty ugly hack. There must be some pseudo-recording running so VDR does not restart the recording

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Matthias Schwarzott wrote: I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin). That would be the way I would do it. Reconstructing the reason for shutdown af

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Matthias Schwarzott wrote: In gentoo vdr package we added a small hack (attached), which implements a svdrp call "down" to tell vdr it is inactive and will shutdown in X minutes. We call this from shutdown-scripts to let vdr retry shutdown in 5 min (or other value if needed). Question is: Is

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[EMAIL PROTECTED] wrote: The alternative would be to implement a generic task scheduler and make timers one special type of schedule. This would get REALLY big. Yes, but it will be the much better design. It will open the option to do VDR related timed and maintainance tasks. There must be s

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Hi list, I've finished a second version of the shutdown rewrite. This time, there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x. http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown - Fixed negative t

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Klaus Schmidinger wrote: However, (don't know exactly if this has already been suggested as such) maybe a simple feature in the new shutdown code could be to allow the user to specify *one* time at which VDR shall be guaranteed to be "up", along with a time period for which it shall stay up. That

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Klaus Schmidinger wrote: Udo Richter wrote: The downside of this would be that again several external tasks would fight for one resource: the time set in VDR. I don't see why "several external tasks would fight for" that time. This is something the user would set up the way he

Re: [vdr] streamplayer - no audio when streaming audio only?

Lars Fredriksson wrote: I'm trying to use VLC to stream an mms:// as MPGA to my VDR-box where I have installed the streamplayer plugin, but I get no sound! Streamplyer says it's receiving a stream and the bitrate show, the buffering value goes up to the value a specify and the starts over from 0

Re: [vdr] error on large EPG loads via SVDRP

Pjotr Kourzanov wrote: I am experiencing VDR errors when loading EPG via SVDRP. If the EPG data to be loaded is larger that 3 MB then VDR silently drops the SVDR connection. Everything is fine if the data is truncated to fit 3 megs. There is an issue if the EPG download is too slow. In th

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Marko Mäkelä wrote: A minor cosmetic thing: the '#' of pre-processor directives should always be located at the first column of the line. The only indented directives are for the debug output I think, and this will probably be removed before the final integration anyway. A more important

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Marko Mäkelä wrote: While VDR is running, I would guess that the only way it can become interactive is by receiving button events from the remote control unit. Hmm, ok, I was mainly thinking of becoming inactive - since this is after a certain time has passed, it can only be polled. For lots o

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Marko Mäkelä wrote: Right, becoming inactive is not that time-critical. I will give your suggestion a try: in the MainThreadHook of each plugin, poll Shutdown.IsUserInactive(). It should work, though the first key press may trigger some longer work, and the MainThreadHook will be called at th

Re: [vdr] FF card A/V sync - in progress?

> wrote: > Werner fixed the A/V sync problem. Please test firmware f12623. > See > http://www.vdr-portal.de/board/thread.php?postid=566692#post566692 I can confirm that the two known issues ('Lost' on ATV and 'Lost' sample by Tero) both play smooth and properly synced

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Marko Mäkelä wrote: The problem seems to lie in shutdown.c, in SystemExecSession(). It won't close file descriptor 0, but it will close anything above STDERR_FILENO (which is normally 2). This function appears to show up in strace output as "clone()". Adding close(0) to the function fixes the p

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

Marko Mäkelä wrote: On Tue, Jan 23, 2007 at 10:19:57PM +0100, Udo Richter wrote: Since the shutdown script runs in the background, the stdin could probably be closed. After all, VDR should continue to 'own' stdin, and running in the background would probably cause a conflict. However

Re: [vdr] Problem with compiling plugins

Kartsa wrote: burn.c:32: error: conflicting return type specified for â ../../../include/vdr/plugin.h:43: error: overriding â The original plugin.h of VDR has this in line 43: virtual cString Active(void); This was introduced on VDR 1.3.47, and conflicts with earlier patches that had thi

<    1   2   3   4   5   6   >