Re: [vdr] Stop live TV whilst in menu
Am 13.05.2011 01:49, schrieb Dominic Evans: > For example, currently if I want to watch two or three recordings one > after another, I go to recordings menu, play 1 till end, hit back > (returning me to recordings menu), play 2 till end and so on. Each > time I go back to the recordings menu to choose the next recording, > I'm forced to see and hear whatever happens to be showing at that time > on the last channel tuned, even when it has no interest to me... I know similar situations where I don't want to have live TV, for example if this would tune to problematic channels (streamdev client) or would interrupt other receivers. Another good solution to this would be a real 'dummy' device, a receiving device that permanently receives a still picture, and that would be assigned to a free channel number. This would also be nice for a playback-only VDR without receiving devices, to avoid the frequent 'channel not available' messages. I've once tried to write such a plugin, however these attempts were missing some code to turn a single mpeg still frame into an endless sequence with proper time codes. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small fix for GCC 4.6 issue
Am 13.05.2011 07:44, schrieb Tobi:
> 8.5/9 of the C++ standard says
>
> "If no initializer is specified for an object, and the object is of
> (possibly cv-qualified) nonPOD class type (or array thereof), the object
> shall be default-initialized; if the object is of const-qualified type,
> the underlying class type shall have a user-declared default constructor.
Interestingly irritating... Since I don't have an GCC4.6 at hand, I
*think* the source of the problem might be that cCursesFont has just an
default constructor. So it should also work if you add an empty
constructor cCursesFont::cCursesFont() { } ???
I thought such an empty constructor would always behave the same as the
default constructor...
Does anyone know the background why the standard doesn't just use the
default constructor for const objects?
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small fix for GCC 4.6 issue
Am 15.05.2011 23:45, schrieb Klaus Schmidinger:
> On 14.05.2011 13:06, Tobi wrote:
>> Right. The C++ standard explicitly requires an "user-declared default
>> constructor" here.
>>
>>> So it should also work if you add an empty
>>> constructor cCursesFont::cCursesFont() { } ???
>>
>> Yes. Either this or -fpermissive. But personally I prefer the initializer
>> here, but I must admit I don't understand the technical reason, why the
>> standard requires a user defined default constructor at all.
>
> I also have to admit that I don't understand what difference this makes.
> Apparently the program works, so the initialization must be taking place,
> even without explicitly calling cCursesFont().
What makes this even more strange to me is the fact, that
static const cCursesFont Font;
requires an user-declared default constructor, while
static const cCursesFont Font = cCursesFont();
creates an temporary non-const cCursesFont object, and then uses the
implicitly declared copy constructor to create the final Font object. So
why is the implicitly declared default constructor forbidden, and the
implicitly declared copy constructor ok?
You'll really need an lawyer when it comes to standards specifications...
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Anybody using VDR-Live with VDR 1.7.18?
Am 07.06.2011 15:07, schrieb John Klimek: > I'm using VDR 1.7.18 with the latest GIT version of VDR-Live and it's > not working that great... > > For example, some images do not appear and then when I try to access > certain links (randomly) VDR will just crash without any errors. I'm using a snapshot of 2011-02-20 together with VDR 1.7.18 and it behaves absolutely normal. Compiled on / against Debian Squeeze. http://projects.vdr-developer.org/git/?p=vdr-plugin-live.git;a=commit;h=cc286c602ffbaed4f8e6d92e50138600c142b69f ||/ Name VersionBeschreibung +++-==-==- ii libc6 2.11.2-10 Embedded GNU C Library: Shared libraries ii libcxxtools6 1.4.8-3library of unrelated but useful C++ classes ii libgcc11:4.4.5-8 GCC support library ii libpcre3 8.02-1.1 Perl 5 Compatible Regular Expression Library ii libpcrecpp08.02-1.1 Perl 5 Compatible Regular Expression Library ii libstdc++6 4.4.5-8The GNU Standard C++ Library v3 ii libtntnet8 1.6.3-4Tntnet libraries Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cppcheck: VDR 1.7.18: [timers.c:53]: (error) snprintf size is out of bounds
Am 15.06.2011 18:34, schrieb Klaus Schmidinger: > On 15.06.2011 15:30, Paul Menzel wrote: >>if (Instant&& channel) >> snprintf(file, sizeof(file), "%s%s", >> Setup.MarkInstantRecord ? "@" : "", *Setup.NameInstantRecord ? >> Setup.NameInstantRecord : channel->Name()); > > ...this should be > > sizeof(file) - 1 Actually, all versions of snprintf documentation I've just checked agree that snprintf will write at most size-1 chars and a trailing 0 byte, so it was ok before too. But for safety, on byte less doesn't hurt. Or is there some broken implementation out there that may write beyond str[size-1]? (strncpy is more broken, thats why my typical usage is: strncpy(dest, src, sizeof(dest)-1); dest[sizeof(dest)-1] = 0; ) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.19
Am 19.06.2011 22:57, schrieb Klaus Schmidinger: > On 19.06.2011 12:41, Klaus Schmidinger wrote: >> - Fixed detecting frames in case the Picture Start Code or Access Unit >> Delimiter >> extends over TS packet boundaries (reported by Johan Andersson). > > I'm afraid this change causes a short distortion in video and audio > when VDR switches from one .ts file to the next during replay. > I have yet to investigate and fix this, just wanted to warn people > who make important recordings with this new version - which, of course, > nobody should do, since it is a developer version ;-) Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would have if I were using a developer version, which nobody would do. ;) Can you provide a diff that reverts just that changeset so we can use all the other goodies of 1.7.19 for now? Eh, could, if we would use developer builds, of course. ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: s2api backwards compatible?
Am 03.07.2011 19:55, schrieb Tony Houghton: > Is s2api backwards compatible ie can you use it on older, non DVB-S2, > cards? It is, in both ways: Any supported DVB card can always be accessed by s2api and by DVB v3 API. Functionality may be limited on DVB v3 API of course. S2api is part of any kernel >= 2.6.28. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer mode vs TS playback: any difference in TS streams for vdr.1.7.19?
Am 11.07.2011 18:12, schrieb Klaus Schmidinger: > On 11.07.2011, at 03:21, Laz wrote: >> Before I dig into buffers, etc., is there any difference between >> the streams sent to PlayTS in transfer mode and in playback? I see that >> transfer mode generates a PAT/PMT on the fly and passes the stream >> directly to PlayTs. > > In Transfer Mode onlx one single PAT/PMT is generated at the very start of it, > while a recording contains a PAT/PMT at the beginning of every GOP. Correct me if I'm wrong, but doesn't transfer mode receive PCR clock data, while playback is without PCR clock? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ring buffer overflows with streamdev and remux script
Am 14.07.2011 02:28, schrieb VDR User: > On Wed, Jul 13, 2011 at 12:05 PM, Luboš Doležel wrote: >> Apart from simplifying the script to a single line I've found a solution: >> I've tripled the size of the ring buffer in vdr-streamdev-server and the >> problem is gone. No problems after hours of playback... > > Is there any reason why the ring buffer can't or shouldn't be dynamic > aside of just not bothering to implement it? Unlimited buffers tend to get unlimited big, crashing your app with out-of-memory. Huge buffers also add lag to the signal. With no bandwidth issues, buffers are usually almost empty, with bandwidth issues, buffers are usually almost full. In the end you set them as big as necessary, and as small as possible. And giving them a fixed size (possibly configurable) is less complicated, especially in a multi-threaded environment. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to convert a JPEG image to an HD video frame?
Am 23.07.2011 16:57, schrieb Klaus Schmidinger: > jpegtopnm $Pict | > pnmscale --xscale=$ScaleW --yscale=$ScaleH | > pnmpad --black --width $SW --height $SH | > ppmtoy4m -F $framerate -I p -S 420mpeg2 | > mpeg2enc -f 3 -b 12500 -a $aspect -q 1 -n $system2 -o $Mpeg > > While this works fine for SD video, I can't seen to figure > out how to make this work for an HD video output device. I've played around with this a bit, but it seems as if at least my mpeg2enc (1:1.9.0-0.7, debian-multimedia.org) doesn't like HD resolutions. It has some support for ATSC HD (-f 13), but then doesn't like european frame rates. Best chances are probably to find some other encoder that accepts an 420mpeg2 pipe as input and can encode HD mpeg2 or h264 out of it. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature suggestion: @include in channels.conf
Am 25.07.2011 11:17, schrieb Harald Milz: > Because the channel list may be modified by the provider every now and then, > and VDR cannot know anything about it, the channels.conf file needs to be > rebuilt frequently outside of VDR (and reloaded on the next VDR restart). You know that you can modify the current channel list by the SVDRP commands LSTC, MODC, MOVC, NEWC? You just need a way to distinguish between 'your' channels and other channels, so you know which to update. > It would be far easier if channels.conf could include > other channels.conf files. How should this be preserved if VDR saves the channels.conf? How should changes to the included files be handled? What happens if I move a channel / all channels out of the included file into the main file? An include structure is more easily handled on files that only get read. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
Am 25.07.2011 13:12, schrieb Hawes, Mark:
> I’ve done some further investigation and as far as I can tell the
> problem appears to be with the value returned by cDiseqc::Codes in
> diseqc.c.
>
> The following trace from 1.7.19 shows the problem:
>
> Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01
> [..]
> Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01
> [..]
> Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01
> The identical trace from 1.7.18 which works correctly looks like this:
>
> Received from diseqc->Codes(n) a pointer 137333125 to : E0 10 38 F4
> [..]
> Received from diseqc->Codes(n) a pointer 137333125 to : E0 31 6B 01
> [..]
> Received from diseqc->Codes(n) a pointer 137333125 to : E1 31 6B 01
Without further trying, my wild guess is that the bug is in the
following code fragment of const char *cDiseqc::Codes(const char *s) const:
int n = strtol(t, &p, 16);
if (!errno && p != t && 0 <= n && n <= 255) {
if (parsing) {
codes[NumCodes++] = uchar(n);
numCodes = NumCodes;
My guess is that it must be "if (!parsing)" instead. The switch seems to
be true for syntax checking from cDiseqc::Parse() (the conf file
parser), and false otherwise. The way it is, the values in codes[] only
change when called from the file parser, and then stay at the last code
sequence that has been parsed forever.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] perfect vdr remote?
Am 26.07.2011 17:49, schrieb VDR User: > Those kind of remotes are cool but I wouldn't want one for daily use. > I prefer direct access to many options with one button press, not > going through menus on a remote screen. >From my experience, the keys I _really_ use, are: (1) Core keys: 0-9, Up/Dn/Left/Right, Menu/Ok/Exit, Color keys, Power, Vol+/- (2) Keys I often use: Timers, Recordings, EPG (3) Nice to have, but not essential: Info, Play/Pause/Stop/Rec/Ffwd/Fbwd (4) Rarely used: Mute, Ch+/-, Audio tracks, Subtitle tracks, Channel list I can use (1) and (2) and some of (3) completely blind. Having them on some kind of touch screen is not an option. And for the record, I'm using two remotes: - MD41169: Cheap but acceptable universal remote. Easy to replace if worn out. - Harmony 300: Very flexible, good price, no gimmicks, though only programmable via web site. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.19
Am 19.06.2011 12:41, schrieb Klaus Schmidinger:
> - The initial channel is now stored by the channel ID in the setup.conf file,
> in
> order to avoid problems in case channels are reordered or deleted (reported
> by
> Lars Bläser).
This change includes a change to cMenuEditChanItem to accept a cString
to a channel id as parameter, however the changes are never written
back. As consequence, the initial channel always reverts to the previous
value when leaving the misc setup menu.
The attached patch fixes this.
Cheers,
Udo
--- menuitems.c.bak 2011-08-10 22:25:25.0 +0200
+++ menuitems.c 2011-08-10 22:30:40.0 +0200
@@ -822,9 +822,14 @@
cChannel *channel = Channels.GetByNumber(*value);
snprintf(buf, sizeof(buf), "%d %s", *value, channel ? channel->Name() : "");
SetValue(buf);
+ if (channelID)
+*channelID = channel->GetChannelID().ToString();
}
- else if (noneString)
+ else if (noneString) {
SetValue(noneString);
+ if (channelID)
+*channelID = "";
+ }
}
eOSState cMenuEditChanItem::ProcessKey(eKeys Key)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MaxVideoFileSize
Am 15.08.2011 18:07, schrieb Dominic Evans: > Apart from FAT16/FAT32/ISO 9660 compatibility reasons, are there any > benefits to keeping MaxVideoFileSize for recordings at <= 2GB? Not from within core VDR. If you want to transfer or post-process video files >2G, you should make sure that everything in the processing pipeline can handle large files. However, you can always split a recording later by changing the file size and do another editing run within VDR. The only exception for VDR is the use of the hard link cutter patch: This patch depends on recordings to be in many small files, to gain speed on editing. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.20
Am 16.08.2011 18:57, schrieb Klaus Schmidinger: > VDR developer version 1.7.20 is now available at Thanks for the new version - at a surprising time. ;) > ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.20.tar.bz2 Just a note: The tar file includes a 0-byte epg.data file and an empty themes sub-folder. > - cSkins::Message() now blocks calls from background threads (thanks to > Michael Eiler for reporting a crash in such a scenario). Unfortunately, this will break the osdserver-plugin, that does call these directly from the network interface thread - though not without first locking the main thread in a safe state. I'll see if I can work around this, or if I can come up with some other solution. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.20
Am 16.08.2011 23:13, schrieb Klaus Schmidinger: > On 16.08.2011 19:56, Udo Richter wrote: >> Am 16.08.2011 18:57, schrieb Klaus Schmidinger: >>> - cSkins::Message() now blocks calls from background threads (thanks to >>>Michael Eiler for reporting a crash in such a scenario). >> >> Unfortunately, this will break the osdserver-plugin, that does call >> these directly from the network interface thread - though not without >> first locking the main thread in a safe state. >> >> I'll see if I can work around this, or if I can come up with some other >> solution. > > Actually cSkins::QueueMessage() is supposed to be used for issuing > messages from a background thread. Sure, however QueueMessage does not wait and does not return an user key press. Osdserver exports all of the message functions, including QueueMessage. I'll probably solve this by a main thread callback, some other parts of OsdServer do this already. A solution / extension on VDR side would be to replace the 'main thread' concept with a 'big VDR lock': A global lock that the main thread releases just before sleeping, and re-locks after waking up. That way, any background thread could use that lock to trap the main thread safely, and use all of the not thread safe parts of VDR that previously were only safely available to the main thread. I think the kernel guys have a big lock they don't use any more, maybe we can get that one. ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Osdserver-0.1.3 and Hard Link Cutter-0.2.2 for VDR-1.7.20
Hi list, Updates for VDR-1.7.20 on my web page: Hard Link Cutter for 1.7.20: Fixes rejects http://www.udo-richter.de/vdr/patches.en.html#hlcutter http://www.udo-richter.de/vdr/patches.html#hlcutter Osdserver-0.1.3: - Fix: Message command blocked from background thread, use callback - Update Makefiles, warnings, etc. http://www.udo-richter.de/vdr/osdserver.en.html http://www.udo-richter.de/vdr/osdserver.html Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [feature request] recording length computation and storage
Am 19.08.2011 15:30, schrieb Steffen Barszus: On 08/19/11 11:46, Steffen Barszus wrote: > i would like to request, that > vdr is storing the length of a recording and make it accessible > to the plug-ins. > > Where it gets stored is not my point, that it can be served from in > meory data read by ScanVideoDir is my point. > > - read&compute by the core > - dont access harddisk for known recordings > - dont do it multiple times, if more then one part of vdr wants to know > it. > > If its only in memory and read by the scanner its fine with me. > > for medium to large recording base we speak about minutes not > milliseconds for reading that data. Maybe some kind of caching mechanism, but please don't calculate the length every time while doing the scan of the video directory. The directory scanner is already slow enough, no need to add these minutes to it. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.20
Am 20.08.2011 12:16, schrieb Klaus Schmidinger: > On 19.08.2011 20:48, Udo Richter wrote: >> Sure, however QueueMessage does not wait and does not return an user key >> press. > > That's by design ;-) > A background thread is not supposed to do this! Osdserver has no other choice. From the main thread, Osdserver could only react once a second, meaning that an average osdserver menu would need 30 seconds to appear. Thus, a completely backgrounded network thread is a must. Osdserver solves this with some complex own locking mechanisms, dirty tricks to force a wakeup of the VDR main thread, and threadsafe shadow copies of non-threadsafe data structures. A global lock would make things a lot easier. >> Osdserver exports all of the message functions, including >> QueueMessage. > > Well, I guess it shouldn't. Would mean, osdserver clients cannot do a simple yes/no query. Not an option. > The kernel developers only recently got rid of this, and they had good > reasons to do so, I guess. I wouldn't want to do that in VDR. You're free to implement a fine-grained locking for all non-threadsafe data structures, like the kernel guys did, but IMHO one big lock is better than none. ;) Anyway, Osdserver is fixed now, and uses a callback from MainThreadHook to do the Skins.Message() call. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] May it be possible to use a fullfeature cards as output device only ?
Am 26.08.2011 14:12, schrieb Dieter Bloms: > the tuner part of my fullfeatured card ist broken, so I want to buy a > nova card and use this fullfeatured card as output device only. > At the moment vdr tries to use this card also as receiver. > So may it be possible to tell vdr it should use this card only for > output ? There's a patch at vdr-portal that allows to disable the tuner of a FF card from the dvbsddevice plugin command line (VDR 1.7 only): http://www.vdr-portal.de/board/thread.php?postid=955899#post955899 Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Undetected channels on transponders switching from DVB-S to DVB-S2
Am 11.09.2011 11:37, schrieb Henning Pingel: And this tackles another small problem: I think that VDR doesn't delete any channels from the channels.conf in any case. So outdated channels have to be removed manually. Has there been an attempt to offer a functionality that VDR makes a note of those channels that get the line "frontend timed out while tuning to channel X" in the syslog and offers those channels for manual deletion via the OSD in a special OSD page called "Outdated channels"? There's currently no 'official' method to track down channels that are no longer announced. There's a trick however: Modify your channels.conf so that all channel names start with [outdated], then start VDR and wait for a full transponder scan to finish. All existing channels will be renamed back to their proper names, and all remaining [outdated] channels can be dropped after some grace period. I use a more advanced variant using a small patch and a plugin, both currently not publicly released: The patch tracks a 'last seen' timestamp to all channels, where 0 means 'not seen since VDR start'. A matching plugin holds a second channel list and periodically syncs with the regular channel list, with the additional info 'first seen' and 'last seen' tracked persistently across VDR sessions. Also, the plugin renames channels that are gone for some time so they can be identified and deleted. This has however two downsides: First, a VDR that hasn't been running for some time will instantly mark all channels gone, and the same thing happens if a source is temporarily unavailable - for me, DVB-T is regularly not plugged, so all DVB-T channels are usually marked as gone. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Undetected channels on transponders switching from DVB-S to DVB-S2
Am 13.09.2011 11:03, schrieb Henning Pingel: That sounds *very* interesting to me. If I can assist you in going public with this patch + plugin, please let me know. I currently don't see a reason to reset the timestamp to zero on VDR start, but I probably just don't get your concept yet. Minimal invasive. The patch has less than 2k size and adds 8 lines of code. For persistent storage it would need either a modification to channels.conf or a separate conf file. Thats why I moved all that to a plugin. Maybe I'll polish and upload the code some time, but the next 3-4 weeks are blocked. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] old recordings are not deleted
Am 21.10.2011 20:47, schrieb cedric.dew...@telfort.nl: > I have installed VDR. It runs great, but it has one problem. It does not > delete my old recordings. I have a lot of recordings, and they all have a > lifetime of 0. See also the following info file: VDR deletes old recordings if - Disk space on the root video directory is less than 1Gb (39 min) - The recording is on the file system(s) of the root video directory - The recording is not edited (does not start with %) - The guaranteed lifetime has expired (99 never expires) - In case of lifetime=0, the current recording needs higher priority than the old recording The first two rules about the root video directory do account for everything within the usual /video.00, /video.01, etc. folders, but not any directory trees mounted to sub-directories. So if you mount a disk to /video/archive, disk space will not count there, and nothing will be deleted. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] old recordings are not deleted
Am 22.10.2011 07:51, schrieb cedric.dew...@telfort.nl: I see. I have 2 partitions, a / partition and a /storage partition. I would like to record to /storage/video/video.00. I have edited /etc/default/vdr so it reads: OPTIONS="-v /storage/video/video.00 -w 60" Still I get the error: Oct 22 07:51:24 localhost vdr: [1579] low disk space while recording, trying to remove a deleted recording... Oct 22 07:51:24 localhost vdr: [1579] ...no deleted recording found, trying to delete an old recording... Oct 22 07:51:24 localhost vdr: [1579] ...no old recording found, giving up So you're using just one video directory, and all of that directory is on one mounted partition. Thats fine. Can you give an example for a complete recording path name that should be ready for deletion in your opinion? For VDR-1.7.x, please also post the info file. Oh, and please don't copy into a new mail, just hit the reply button, and make sure it goes to vdr@linuxtv.org. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR segfault with cable provider Unitymedia (DE)
Am 25.10.2011 01:41, schrieb Juergen Judt: I have problems with the VDR because I get segfaults every ~5-10 minutes. Similar problems are also reported in the VDR-Portal --> www.vdr-portal.de/board60-linux/board14-betriebssystem/board69-c-t-vdr/p1025768-segfault-mit-vdr-1-7-21/?highlight=#post1025768 The reason seems to be that for some reason d->getDescriptorNumber() is greater than d->getLastDescriptorNumber(). Did you try the patch that Zabrimus posted on Oct 11? It doesn't fix the invalid descriptor number, but at least it handles the bug gracefully and doesn't crash any more. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Hard Link Cutter 0.2.2 for VDR-1.7.22
Hi list, Hard Link Cutter is updated for VDR-1.7.22 available for download: http://www.udo-richter.de/vdr/patches.en.html#hlcutter http://www.udo-richter.de/vdr/patches.html#hlcutter Original patch by Ville Skyttä, adapted to the variant that VDR-1.7.22 uses. Not intensely tested, but should work. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Fix build with g++ 4.7.0.
Am 04.01.2012 21:04, schrieb Ville Skyttä:
> This is the PR24163 case mentioned in
> http://article.gmane.org/gmane.linux.redhat.fedora.devel/157671
>
> diff --git a/config.h b/config.h
> index 7825364..b0233a9 100644
> --- a/config.h
> +++ b/config.h
> @@ -122,7 +122,7 @@ public:
> if (!isempty(s)) {
> T *l = new T;
> if (l->Parse(s))
> - Add(l);
> + this->Add(l);
> else {
>esyslog("ERROR: error in %s, line %d", fileName, line);
>delete l;
This is one of the cases where it seems appropriate to have a lawyer for
every C++ coder, just in case he needs to wrangle the standard...
For info, the above references 14.6.2/3 of the ISO C++ standard, which is:
> In the definition of a class template or a member of a class template, if a
> base class of the class template
> depends on a template-parameter, the base class scope is not examined during
> unqualified name lookup
> either at the point of definition of the class template or member or during
> an instantiation of the class tem-
> plate or member. [Example:
> typedef double A;
> template class B {
>typedef int A;
> };
> template struct X : B {
>A a;// a has type double
> };
> The type name A in the definition of X binds to the typedef name defined
> in the global namespace
> scope, not to the typedef name defined in the base class B. ]
In our case, I'm not sure if another solution would be to pull in the
Add() method manually, by adding an
using cList::Add;
to the class definition.
There's a similar use of this->First() in Save() that already requires
the this-> in current compilers, and it can also be resolved by an
using cList::First;
.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
Am 07.01.2012 01:17, schrieb René: > ERROR: loading plugin libvdr-epgsearch.so.1.7.22: undefined symbol: > _ZN6cTimerC1EbbP8cChannel > ERROR: loading plugin libvdr-skinenigmang.so.1.7.22: undefined symbol: > _ZN6cTimerC1EbbP8cChannel > ERROR: loading plugin libvdr-text2skin.so.1.7.22: undefined symbol: > _ZN6cTimerC1EbbP8cChannel > ERROR: loading plugin libvdr-burn.so.1.7.22: undefined symbol: > _ZN8vdr_burn13chain_archiveC1ERNS_3jobE > ERROR: loading plugin libvdr-streamdev-server.so.1.7.22: undefined > symbol: _ZN6cTimerC1EbbP8cChannel The cryptic symbol decodes to cTimer::cTimer(bool, bool, cChannel*), found in timers.h, line 46. The actual code is in timers.c, line 28. This function exists in this form since 1.3.38. VDR itself seems to be fine, so your VDR seems to have a different function instead. However, the plugins rely on the original function because they somehow compiled against the original definition in the timers.h. My guess is that one of the patches is optionally modifying this, and the plugins were somehow compiled with different versions of the timers.h, or with different compiler flags that cause some #ifdef to flip. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
Am 07.01.2012 16:27, schrieb Marc: > The problem come from the livebuffer patch. It redefines cTimer::cTimer > to add the length of the already buffered stream so when the instant > recording start, it records the buffer too : > +#ifdef USE_LIVEBUFFER > + cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = > NULL, int Forerun = 0); > +#else >cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = > NULL); > +#endif /*USE_LIVEBUFFER*/ Looks like thats it. However, beside the actual problem, there also seems to be a serious problem with compiler flags, or otherwise this should have worked. More precisely, VDR itself was compiled with USE_LIVEBUFFER, while at least some plugins were compiled without USE_LIVEBUFFER. This should be fixed too, as there may be more serious issues when headers get interpreted differently by VDR and plugins. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Am 08.01.2012 21:10, schrieb Klaus Schmidinger: > On 08.01.2012 20:45, Lars Hanisch wrote: >> Not really, because the driver changes introduced by Manu are on its >> way into linux-media. After that only one frontend will be left and >> new ioctls are there to switch between delivery systems. >> Rumours say Klaus is working on it for vdr 1.7.23... :-) > > Version 1.7.23 will contain multi frontend support with the new API. Will 1.7.23 require a kernel with the new API or will it be backwards compatible? Otherwise, s2apiwrapper ftw! ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] howto ignore lines in channels.conf
Am 15.01.2012 14:49, schrieb fnu: > Well that is an other question and valid argument, why is there no > sufficient solution to scan for channels in VDR, like is quit normal on > commercial solution. I've been living with VDR's auto channel update quite well, back since VDR 1.3.x eliminated the need of the AutoPID patch. The only thing I need an external tool for is to clean up all the dead channels from time to time. I never understood why people need external scan tools anyway, at least on an average system. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] S2API wrapper for VDR-1.7.23 (also upgrades 5.x to 5.3 API)
Hi list, And here I was, thinking that I could finally drop support for this old compatibility patch that noone really needs any more, and then the new VDR-1.7.23 requires linux-3.0 or newer headers to compile... yay... So here it is again: S2API Wrapper 0.8 is released, and should allow to compile a fully functional VDR on any DVB API headers from version 3.0 to 5.3, plus being able to use all features if the compiled binary is run on a newer kernel. Download: http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 20.02.2012 10:18, schrieb Klaus Schmidinger:
> On 20.02.2012 00:06, Joerg Riechardt wrote:
>> With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is
>> ok again.
>> Other patches were not involved.
>> Jörg
>
> Well, then I guess it's best if I revoke that change.
> Any objections? Or maybe a fix for the vdr-xine problem?
>
> (See also
> http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1054305-geloest-timeshift-problem-mit-1-7-x/#post1054305).
I'm also seeing (hearing) reproducible glitches on playback with a
TT-6400, on 1.7.24. I've reverted just the changes from the patch at
vdr-portal, and the glitches were gone. So +1 for reverting.
For ease of use the attached patch sums up the revert. Because of an
indenting issue the original patch doesn't revert cleanly.
Cheers,
Udo
--- vdr-1.7.24/dvbplayer.c.bak 2012-02-20 22:51:24.0 +0100
+++ vdr-1.7.24/dvbplayer.c 2012-02-20 22:55:26.0 +0100
@@ -87,7 +87,6 @@
private:
cUnbufferedFile *f;
uchar *buffer;
- uchar *result;
int wanted;
int length;
cCondWait newSet;
@@ -101,7 +100,7 @@
void Clear(void);
void Request(cUnbufferedFile *File, int Length);
int Result(uchar **Buffer);
- bool Reading(void) { return result; }
+ bool Reading(void) { return buffer; }
bool WaitForDataMs(int msToWait);
};
@@ -110,7 +109,6 @@
{
f = NULL;
buffer = NULL;
- result = NULL;
wanted = length = 0;
Start();
}
@@ -120,7 +118,6 @@
newSet.Signal();
Cancel(3);
free(buffer);
- free(result);
}
void cNonBlockingFileReader::Clear(void)
@@ -129,8 +126,6 @@
f = NULL;
free(buffer);
buffer = NULL;
- free(result);
- result = NULL;
wanted = length = 0;
Unlock();
}
@@ -142,18 +137,18 @@
wanted = Length;
buffer = MALLOC(uchar, wanted);
f = File;
- newSet.Signal();
Unlock();
+ newSet.Signal();
}
int cNonBlockingFileReader::Result(uchar **Buffer)
{
LOCK_THREAD;
- if (result && length == wanted) {
- *Buffer = result;
- result = NULL;
+ if (buffer && length == wanted) {
+ *Buffer = buffer;
+ buffer = NULL;
return wanted;
- }
+ }
errno = EAGAIN;
return -1;
}
@@ -177,8 +172,6 @@
length = wanted = r; // this will forward the error status to the caller
}
if (length == wanted) {
- result = buffer;
- buffer = NULL;
cMutexLock NewDataLock(&newDataMutex);
newDataCond.Broadcast();
}
@@ -190,9 +183,9 @@
bool cNonBlockingFileReader::WaitForDataMs(int msToWait)
{
- if (result && length == wanted)
- return true;
cMutexLock NewDataLock(&newDataMutex);
+ if (buffer && length == wanted)
+ return true;
return newDataCond.TimedWait(newDataMutex, msToWait);
}
@@ -415,13 +408,13 @@
Goto(0, true);
while (Running()) {
if (WaitingForData)
- nonBlockingFileReader->WaitForDataMs(10); // this keeps the CPU load low, but reacts immediately on new data
+ nonBlockingFileReader->WaitForDataMs(3); // this keeps the CPU load low, but reacts immediately on new data
else if (Sleep) {
cPoller Poller;
DevicePoll(Poller, 10);
Sleep = false;
if (playMode == pmStill || playMode == pmPause)
- cCondWait::SleepMs(10);
+ cCondWait::SleepMs(3);
}
{
LOCK_THREAD;
@@ -483,15 +476,7 @@
}
if (!eof) {
uchar *b = NULL;
- int Retries = 5;
- int r;
- while (true) {
- r = nonBlockingFileReader->Result(&b);
- if (r == -1 && errno == EAGAIN && --Retries)
-nonBlockingFileReader->WaitForDataMs(10);
- else
-break;
- }
+ int r = nonBlockingFileReader->Result(&b);
if (r > 0) {
WaitingForData = false;
uint32_t Pts = 0;
___
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
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. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Prefer non-CI equipped adapters for FTA channel recording
Am 23.02.2012 10:30, schrieb Klaus Schmidinger: > Just check what's actually happening in the GetDevice() function. ... and try with minimal plugins, they might introduce side effects. OSDTeletext for example is known to have such side effects on device selection. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
> On 24.02.2012 15:37, Frank Schmirler wrote:
>> On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
>>> - Fixed handling the PrimaryLimit when requesting a device for live
>>> viewing
>>> (reported by Uwe Scheffler).
Hmmm, didn't even notice that change...
>> Anyway, I think a better way to fix the problem would be to change the
>> priority parameter of the GetDevice calls involved from
>> "GetDevice(channel, 0,
>> true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are
>> two calls
>> in device.c and one call in menu.c.
My 'volatile' patch did this, and it worked so far. I like that a lot
more than the 1.7.24 solution that just adds another quirk to the
priority system. If in doubt, this should just raise the priority on
channel switching. I don't think that it would cause any negative side
effects, esp. since this priority is ignored at the end anyway. (see below)
> IIRC that whole "Primary Limit" thing was introduced because in the
> beginning
> the full featured DVB cards were unable to record and play at the same
> time.
> So it could happen that a timer occupied the primary device and left the
> user with a black screen. Since the old FF cards have been given the
> ability
> to do simultaneous recording and replay a long time ago, and the new TT
> S2-6400
> has been able to do this from the very start, I'd rather prefer to do
> away with
> the "Primary Limit" altogether - to make things simpler instead of more
> complex ;-)
Keep in mind that a recording on an un-modded SD-FF device nowadays can
cause broken recordings because of limited bandwidth. Being able to
record and play at the same time is a rather theoretical ability,
especially if its transfer mode playback.
However, I never had PrimaryLimit set to anything but 0.
> http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-4.diff
For description:
http://projects.vdr-developer.org/issues/show/10
> Well, I don't like the idea of introducing yet another parameter
> ("volatile") here.
> The "priority" should be sufficient to solve this. So if you can suggest
> a solution
> that works solely with priorities, I might take a look ;-)
That patch actually goes the same way as the above fix, but beside that
its more about the detaching issue, and just fixed the PrimaryLimit
issue on the way, so its not directly related. Even dropping
PrimaryLimit wouldn't solve this issue.
One of the core problems is that VDR selects a new device for live
viewing before disconnecting the old live device. Thus, all live related
receivers will still be present and will block the current device from
being re-used. VDR works around this just because live view has no
receivers (FF cards) or -1 priority receivers (transfer mode,
subtitles), that are always of lower priority than anything.
As a conequence, VDR has to ignore the '-1 can always be disconnected'
rule, or it would also disconnect transfer mode on timers, regardless of
free devices. And this leads to the osdteletext issue that the teletext
receiver still blocks the device on channel switch. VDR's own receivers
also work around this because they get disconnected before doing the
final and counting GetDevice call, but plugins cannot do that at that time.
A clean solution should imho do these things:
- Fix the find-device-before-disconnecting loop
- Transfer mode devices with 'real' priorities
- Honor the -1 priority as always-detachable
In the end, you need to know at a very early point (ChUp pressed etc.)
whether a device will be available for live view, even if it is still
used right now, and might be used on (if ChUp fails).
Letting VDR know that a device will probably soon be detached was one of
the smarter solutions to this. Another alternative I was thinking of was
to let the device know that a receiver is 'live-related', and thus can
be canceled for another live view, but the 'volatile' solution was more
general.
Maybe it would be possible to manually lower the transfer mode receivers
to -1 when calling GetDevice with live view, and raise them back to
PrimaryLimit (or 0) at the end. Not sure if that's more elegant...
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 27.02.2012 14:33, schrieb Frank Schmirler: > Instead of a configurable "LiveTV priority", your approach uses the fixed > priority value 0 for LiveTV. The new idle priority of -100 opens the range for > cReceivers with negative priority. The problem is, that *any* negative > priority is still considered as "may be detached anytime", so there's still no > real "cReceiver with less priority than live TV". Unfortunately not, because "may be detached anytime" is intentionally broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live TV freeze on recording start" bug. Extending this to priorities down to -99 doesn't change anything, and I currently see no real advantage in it: Why would someone want an unimportant stream with priority -10, and another with -20? VDR itself doesn't use them, so anything below 0 would be the same. Maybe, with some ugly hacks, Streamdev could emulate the old PrimaryLimit by adding some kind of priority offset to all streams, but as long as the rest is all broken, there's no real point in it. > - instead of any negative priority, only priority -MAXPRIORITY gets the > special meaning of "may be detached anytime" See above. Would require transfer mode to run on -99 too, otherwise would re-introduce live TV freeze. > - the constructor of cReceiver should use default priority -MAXPRIORITY, so > not all plugins have to be updated to keep their previous behaviour > - use LIVEPRIORITY-1 as priority for cTransfer Such -1 offset workarounds usually don't work, I would prefer not to have them. For example, one transfer device can still block another before detaching or via Streamdev. The only consistent solution is to give transfer mode the same priority as primary device live priority, either PrimaryLimit or 0. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 29.02.2012 17:50, schrieb Tony Houghton: > On Wed, 29 Feb 2012 16:48:33 +0100 > Manuel Reimer wrote: >> What does this mean? Do you plan built-in networking support or do >> you plan to improve streamdev? IMHO it is a big task to make really >> good networking support. Keeping this code separate (means: A plugin) >> isn't a that bad idea, I think. Of course, this plugin could be >> delivered directly with VDR, like the other "built-in" plugins. > > I don't think a plugin is enough. For better client-server VDR > needs to support multiple clients watching different channels with > different OSDs simultaneously. Not necessarily. I think the key solution is to modularize VDR's internal structures, with well defined interfaces between them. A receiving module that provides stream sources, a recording module that does all the timer work, a frontend module that can display, a storage module that can store and provide videos, for example. A timer menu that belongs to a recording backend, a recording menu that displays content of storage modules, several frontends that can connect to one recording backend or several storage modules, and all can connect to different sources. With defined and pluggable structures between them, its easy to have them either locally connected or linked over network. Whether that's done by a plugin or VDR internally doesn't matter. In any case this would be the biggest rewrite of major parts of VDR ever, with lots of breakage, total loss of plugin compatibility and very long development cycle. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 29.02.2012 16:17, schrieb Klaus Schmidinger: > + The function cDevice::Receiving() now returns true if there is any > receiver > attached to the device. Its boolean parameter has no meaning any more. Please remember to drop the following line from PLUGINS.html, as it is now finally completely void: > (any negative value will allow a cReceiver to be detached from its cDevice at > any time.) This was handled via Receiving(true). This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug. What about having yet another plugin callback that fires before switching a live channel? Currently, plugins get notified after channel change, and thats too late to disconnect receivers early. And since receiving at -1 doesn't have any special meaning any more, there's no way to get receivers out of way early enough. Roughly, the callback should be at the places where these two get called: DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter); (Thats how VDR's own receivers get out of way.) That way, GetDevice(ch, 0, true) will still have the weired behavior of returning different devices before and after initiating the live view channel switch, but at least after disconnecting all live related receivers, the correct device will be returned. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 01.03.2012 06:37, schrieb Gero: >> A timer menu that belongs to a recording backend, a recording menu that >> displays content of storage modules, several frontends that can connect >> to one recording backend or several storage modules, ... > > I think, here is already the first shortcoming in design. May be cause you're > thinking with today plugins in mind? You got me wrong on that. My vision would be that timer UI and recording backend are two modules, and in a more complex environment there may be several UI frontends connected to one (or more?) recording backends. Any client should be able to edit timers on the server independently, the backend shouldn't even have any UI. In fact, any UI should be located in the frontend. For all sxfe fans: A frontend implementation itself could split into two parts, one server-side frontend, and one lightweight stream&OSD display. Or keep latency low and put a more complex frontend on the client, that acts independently of the server backend. A high-level frontend could connect to one or more receiver backends to get channels on demand, would be able to schedule timers on recording backend(s), and would be able to play back from storage sources. Why not allow a storage plugin to act as a media player instead of just VDR recording server? Or on-the-fly transcoding on recording? > Additionally it should be possible to configure the preferred input device > used > by this client for life-view. Other devices may be configured as fallback, in > case the preferred device is not available. Thought of that. Generally, the default link between video frontend and receiver backend should be handled like transfer mode, to make things more unique. For the case of FF cards, there could be an additional prefer-this-backend-for-this-frontend rule, and a shortcut in transfer control that routes the video stream within the card instead of user space. > As I already wrote, from my point of view, plugins may continue do > networking, > but the connection between backend- and frontend-part of vdr should not be > public nor affected by any plugin. Well, I have a different vision: More like recording server and streaming client, where all the UI logic resides in the client, and the server doesn't need to know about UI at all. One advantage: Allow a frontend to connect to more than one backend. For example, have two 'full' VDR systems with receivers, recording capabilities and storage, and some streaming clients. And then let each of them use any receiver, any recording capability, and any recording storage that is available. As said, the server itself could spawn several clients, so sxfe-like lightweight viewers can connect to it. There could also be shortcuts if backends are on the same machine or in the same executable, so not everything must go over network. However, thats all pretty much vision and far from being reality. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 01.03.2012 07:03, schrieb VDR User: > one option to spread > the workload could be Klaus assigning different portions to different > contributors that would like to work on it. If Klaus is clear about > what he wants and is in good communication with other coders, perhaps > it could become more of a team effort with Klaus as team captain.. The number of Klaus per VDR has always been quite limited. A developer team would surely speed things up, but I also understand that Klaus prefers to keep all development in his own hands instead of delegating and supervising. Letting 'his baby' off the hook isn't easy, and I would understand if he prefers to keep it under control. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 01.03.2012 22:25, schrieb Klaus Schmidinger: > Guys, *please*! I stated earlier that I am currently concentrating > on making a stable version 2.0, and that I will see to make client/server > a priority *after* that. Agreed, lets focus on 2.0 for now. We just got carried away dreaming of VDR 3.0 already. ;) Its never too early to dream tho'... Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 02.03.2012 11:35, schrieb Jarkko Kangas: > On 2.3.2012 12:17, Pertti Kosunen wrote: >> It would be great if next stable could include ttxtsubs-plugin >> readiness, i.e. recording/viewing teletext subtitles would not require >> patching of main VDR code anymore. > > It would be also great if next stable could include mainmenuhooks-patch > so extrecmenu- and epgsearch-plugins would not require patching VDR code > anymore. It would be also great if next stable would include the other 13 patches that I regularly use, but I doubt it. Throwing every wish into it would probably delay it forever, esp. for patches like mainmenuhooks that is planned to be superseded by more general planned changes at some point. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 02.03.2012 11:06, schrieb Klaus Schmidinger: > On 29.02.2012 21:33, Udo Richter wrote: >> Roughly, the callback should be at the places where these two get called: >> >> DELETENULL(liveSubtitle); >> DELETENULL(dvbSubtitleConverter); >> >> (Thats how VDR's own receivers get out of way.) > > There are two places in GetDevice() where > cStatus::MsgChannelSwitch(this, 0) > is called, but they are both *after* the final call to GetDevice(). > And there is this comment > > // only report status if we are actually going to switch the channel > > which refers to a change that was made in version 1.1.10: > > - Only calling cStatus::MsgChannelSwitch() if a channel is actually > going to > be switched or has actually been switched successfully (thanks to Stefan > Huelswitt). Good point. What if VDR wants to switch, but fails. Is it possible that the channel change still fails after deleting liveSubtitle and dvbSubtitleConverter? How does VDR itself handle this? Need to investigate this. If a call to MsgChannelSwitch(this, 0) was done on channel change, we have to make sure that the corresponding call for the new channel does happen, or - worst case - there's a call for the old channel again. > What I really see as a problem here now is that the first call to > GetDevice() may call a device's DetachAllReceivers() and the second > GetDevice() call may then decide to actually use a different device. > I'm currently considering giving GetDevice() another parameter: > > static cDevice *GetDevice(const cChannel *Channel, int Priority, bool > LiveView, bool Query = false); +1, as I know that something like this was on some wish lists for some time. ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 02.03.2012 10:30, schrieb fnu: > You want to have a feeling how it feels, if a live buffer is the underlying > central function in a PVR solution, just go and test MythTV. I think the main objection against buffering was that for old FF cards, this also forces transfer mode, resulting in additional lag and bandwidth issues. Since HDFF cards AFAIK can split their stream on card for live view and recording, this isn't valid any more. Live viewing could be just like its currently, with an additional (RAM?) recording running in the background, and VDR could jump to that recording on rewind/pause key hit. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [OsdTeletext] detach receiver for VDR 1.7.25
Hi list,
To actually make use of the new MsgChannelSwitch behavior of VDR 1.7.25,
I've quickly hacked an experimental patch to use this to detach the old
receiver before VDR attempts to switch channel. With this, channel
switching should not jump between receivers for FF cards, avoiding
transfer mode whenever possible. Please test.
Cheers,
Udo
--- osdteletext/txtrecv.c.bak 2012-03-03 15:11:53.0 +0100
+++ osdteletext/txtrecv.c 2012-03-03 15:19:27.0 +0100
@@ -485,6 +485,15 @@
void cTxtStatus::ChannelSwitch(const cDevice *Device, int ChannelNumber)
{
+#ifdef VDRVERSNUM >= 10725
+ // Disconnect receiver if channel is 0, will reconnect to new
+ // receiver after channel change.
+ if (ChannelNumber == 0 && Device->IsPrimaryDevice()) {
+ delete receiver;
+ receiver = NULL;
+ }
+#endif
+
// ignore if channel is 0
if (ChannelNumber == 0) return;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OsdTeletext] detach receiver for VDR 1.7.25
Am 03.03.2012 21:40, schrieb Andreas Brachold: > It should be : > -- > #if VDRVERSNUM >= 10725 Ouch, you're right, of course... COMPILER! Y U NO ERROR? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Segfault in dvbhddevice
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. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.26
Am 10.03.2012 16:18, schrieb Klaus Schmidinger: > Any plugins that implement cStatus::ChannelSwitch() need to add the > parameter > 'bool LiveView' to that function. The 'status' plugin, part of the VDR source, does not yet use the new LiveView parameter. Just one of many plugin breakages. People should look out for warnings like this: > ../../../include/vdr/status.h:33: warning: ‘virtual void > cStatus::ChannelSwitch(const cDevice*, int, bool)’ was hidden > status.c:21: warning: by ‘virtual void cStatusTest::ChannelSwitch(const > cDevice*, int)’ This usually means that channel switch reporting is no longer working! People with C++11 compatible compilers can enable C++11 support and add another declaration like this to cStatus: > virtual void ChannelSwitch(const cDevice *Device, int ChannelNumber) final; That will cause the wrong parameters to be treated as an error. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.26
Am 11.03.2012 16:58, schrieb Klaus Schmidinger: > On 11.03.2012 16:05, Anssi Hannula wrote: >> -Werror=overloaded-virtual > > Thanks. I'll change the Makefiles accordingly. We'll see how many false errors this will have. With my quick&dirty fix (see vdrportal) it still complains about overloaded virtuals, even though it does replace one of the virtual base functions exactly. Final and override are the only two features of C++11 I'm already using (with some macro magic for compatibility). They add a lot of safety to virtual overloading. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Hard Link Cutter for VDR-1.7.27
Hi list, A bit late, but finally a fixed version of Hard Link Cutter for 1.7.27 is uploaded on my web page. I got ninja'd by Ville Skyttä anyway, so most credits go to him this time. Also: Finnish and German translation included. http://www.udo-richter.de/vdr/patches.en.html#hlcutter http://www.udo-richter.de/vdr/patches.html#hlcutter Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Am 06.04.2012 15:01, schrieb Christopher Reimer: > could someone please review the attached patch? It's originally posted > by Maniac in this thread --> On the original topic, I see room for one improvement: The defaults of the new --cachedir and --resdir parameter are the defaults set by Make.config's CACHEDIR and RESDIR. This is a minimal change in behavior to previous versions, where these were handled by --video and --config. So any old VDR that gets updated will behave different in case that --video or --config is set, and now needs to also have --cachedir and --resdir set. On the other hand, there needs to be a way for distributions to set their defaults so that VDR finds them automatically. My suggestion: Allow to keep the default CACHEDIR and RESDIR un-set (empty), and if --cachedir or --resdir is not present, default to whatever --video and --config is actually set to. That way, the package builder can decide whether to set CACHEDIR and RESDIR or not, and if they're set, he has to make sure that the startup scripts get modified to support --cachedir and --resdir if necessary. For an extra, an explicit --cachedir="" and --resdir="" could also override an explicit CACHEDIR and RESDIR and revert to duplicating --video and --config. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Am 08.04.2012 09:48, schrieb Manuel Reimer:
> It is difficult to read your description (and no, I didn't understand
> it). How would you want to document this in a way, someone actually
> understands it?
I guess I have to find a way to be more clear...
Ok, second attempt:
- Makefile does not set CACHEDIR and RESDIR
- Make.config *can* set CACHEDIR and RESDIR, or not.
- If --cachedir or --resdir is set by command line, use them.
- If not, default to CACHEDIR and RESDIR.
- If CACHEDIR or RESDIR is not set (empty string), fall back to whatever
--video and --config is set to.
Patched patch attached. ;)
Needs documentation updated though.
Cheers,
Udo
diff -ruN vdr-1.7.27/INSTALL vdr-1.7.27.patched//INSTALL
--- vdr-1.7.27/INSTALL 2012-02-27 12:03:14.0 +0100
+++ vdr-1.7.27.patched//INSTALL 2012-04-06 09:43:38.590832504 +0200
@@ -375,6 +375,18 @@
VDR archive into your video directory (or into your config directory,
respectively, in case you have redirected it with the -c option).
+If you prefer to have your system set up according to the FHS
+("File system Hierarchy Standard") and thus have all your files spread
+around the entire file system, you can do this by adding a Make.config
+file with the following settings
+
+CACHEDIR = /var/cache/vdr
+CONFDIR = /var/lib/vdr
+LOCDIR = $(PREFIX)/share/locale
+PLUGINLIBDIR = $(PREFIX)/lib/vdr
+RESDIR = $(PREFIX)/share/vdr
+VIDEODIR = /srv/vdr/video0
+
Setting up DiSEqC:
--
diff -ruN vdr-1.7.27/Make.config.template vdr-1.7.27.patched//Make.config.template
--- vdr-1.7.27/Make.config.template 2012-03-20 12:20:13.0 +0100
+++ vdr-1.7.27.patched//Make.config.template 2012-04-06 09:43:38.591832504 +0200
@@ -33,6 +33,8 @@
PLUGINLIBDIR = $(PLUGINDIR)/lib
VIDEODIR = /video
CONFDIR = $(VIDEODIR)
+#CACHEDIR = $(VIDEODIR)
+#RESDIR = $(CONFDIR)
### The remote control:
diff -ruN vdr-1.7.27/Makefile vdr-1.7.27.patched//Makefile
--- vdr-1.7.27/Makefile 2012-03-11 16:33:57.0 +0100
+++ vdr-1.7.27.patched//Makefile 2012-04-06 10:06:28.004832504 +0200
@@ -29,6 +29,8 @@
VIDEODIR = /video
CONFDIR = $(VIDEODIR)
+#CACHEDIR = $(VIDEODIR)
+#RESDIR = $(CONFDIR)
DOXYGEN ?= /usr/bin/doxygen
DOXYFILE = Doxyfile
@@ -71,6 +73,8 @@
DEFINES += -DVIDEODIR=\"$(VIDEODIR)\"
DEFINES += -DCONFDIR=\"$(CONFDIR)\"
DEFINES += -DPLUGINDIR=\"$(PLUGINLIBDIR)\"
+DEFINES += -DCACHEDIR=\"$(CACHEDIR)\"
+DEFINES += -DRESDIR=\"$(RESDIR)\"
DEFINES += -DLOCDIR=\"$(LOCDIR)\"
# The version numbers of VDR and the plugin API (taken from VDR's "config.h"):
@@ -112,6 +116,8 @@
@echo "configdir=$(CONFDIR)" >> $@
@echo "videodir=$(VIDEODIR)" >> $@
@echo "plugindir=$(PLUGINLIBDIR)" >> $@
+ @echo "cachedir=$(CACHEDIR)" >> $@
+ @echo "resdir=$(RESDIR)" >> $@
@echo "localedir=$(LOCDIR)" >> $@
@echo "apiversion=$(APIVERSION)" >> $@
@echo "cflags=$(CXXFLAGS) $(DEFINES) -I\$${includedir}" >> $@
@@ -183,7 +189,7 @@
# Install the files:
-install: install-bin install-conf install-doc install-plugins install-i18n install-includes install-pc
+install: install-bin install-dirs install-conf install-doc install-plugins install-i18n install-includes install-pc
# VDR binary:
@@ -193,12 +199,15 @@
# Configuration files:
-install-conf:
+install-dirs:
@mkdir -p $(DESTDIR)$(VIDEODIR)
- @if [ ! -d $(DESTDIR)$(CONFDIR) ]; then\
- mkdir -p $(DESTDIR)$(CONFDIR);\
- cp *.conf $(DESTDIR)$(CONFDIR);\
- fi
+ @mkdir -p $(DESTDIR)$(CONFDIR)
+ @mkdir -p $(DESTDIR)$(RESDIR)
+ @mkdir -p $(DESTDIR)$(CACHEDIR)
+
+install-conf:
+ @cp *.conf $(DESTDIR)$(CONFDIR)
+
# Documentation:
diff -ruN vdr-1.7.27/PLUGINS.html vdr-1.7.27.patched//PLUGINS.html
--- vdr-1.7.27/PLUGINS.html 2012-03-09 10:49:29.0 +0100
+++ vdr-1.7.27.patched//PLUGINS.html 2012-04-06 09:43:38.594832504 +0200
@@ -82,7 +82,7 @@
Wakeup
Setup parameters
The Setup menu
-Configuration files
+Additional files
Internationalization
Custom services
SVDRP commands
@@ -885,39 +885,55 @@
your setup parameters and use that one to copy all parameters with one single statement
(like VDR does with its cSetup class).
-Configuration files
+Additional files
I want my own stuff!
-There may be situations where a plugin requires configuration files of its own, maybe
-for data that can't be stored in the simple setup parameters
-of VDR, or maybe because it needs to launch other programs that simply need a separate
-configuration file. While the plugin is free to store such files anywhere it
-sees fit, it might be a good idea to put them in a common place, preferably
-where other configuration data already exists. VDR provides the function
+There may be situations where a plugin requires own files. While the plugin is
+free to store such files anywhere it sees fit, it might be a good idea to put them in a common
+place, preferably where such data already exists.
+
+configuration files, maybe for data that can't be stored in the simple
+setup parameters of VDR, or may
Re: [vdr] OT: video dir symlink [WAS:Filesystem hierachy standard patch needs review.]
Am 08.04.2012 11:36, schrieb Klaus Schmidinger: > At any rate, I want to get rid of that symlink stuff and allow > VDR to "see" only one big video directory. Sorry for being OT, just wanted to extend my thought of the last post-2.0-offtopic discussion: Modularize. Defining an interface for 'video storage' thingys, together with the ability to have several storages loaded at the same time, would allow to have plain old /video storage and (maybe as plugin) remote network storages. It would also allow to have more than one local storage. (Maybe a storage backend that read/writes AVI or MKV?) And if the old, ugly symlink system gets dropped, it could even be continued by a compatibility plugin. There are tons of more possibilities here, but we should delay that to post-2.0. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Am 09.04.2012 11:54, schrieb Klaus Schmidinger: > However, there is one thing in the current behavior that I would even > consider a bug: if one starts VDR with > > vdr -v /mydir > > it uses /mydir as the video directory, but still uses /video for the > configuration files. I believe that as long as there is no explicit > -c option given, the config directory should follow what's given in > the -v option. You're sure about -c following -v? It worked that way until 1.5.8, but has been dropped in favor of the final changes regarding CONFDIR in 1.5.11. I don't see any reason to change that. Or did you mess up --config with --cachedir? Happened to me too. In the latter case: In my patch, the cacheDirectory follows the VideoDirectory, even if the latter is set by --video, but only as long as CACHEDIR is un-set. (Same applies to --config and RESDIR.) I'm not sure whether this should also be the case if VDR is compiled to be FHS compliant. In that case users should know about the various folders, and setting a --video directory should not have precedence over CACHEDIR=/var/lib/vdr. The only thing I could think of is to check whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow --video, but I would prefer to not use such hacks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Understanding the dataflow
Am 20.04.2012 23:58, schrieb Roland Tapken: > What is cPlayer? As cTransfer implements both cReceiver and cTransfer I > thought about it as some kind of frontend abstraction (FF-output, xine, > streamdev-server). But it seems that cPlayer directly acts on cDevice, and > that doesn't make sense to me at the moment. > > Furthermore, I'm still not quote sure where all these components where > attached to each other. A cDevice can be both, input device and output device. A cReceiver can generally receive stream data like video, audio, subtitles, teletext, EPG, and so on, from a device. A cPlayer provides video/audio data for replay and feeds it into the output device. A cControl acts as the controlling interface of a cPlayer. It can handle keyboard and OSD interaction for a cPlayer device. A cTransfer is a cReceiver and a cPlayer, and just pumps data between these two. One thing to understand is that a cDevice can be stream source and output device at the same time. Generally, if you switch to a channel, the output device will be asked to show a specific channel. Only if the device itself is unable to do this on its own, a different device will provide the video stream, and a cTransfer is created to transport all the data from the receiving to the output device. 'Full Featured' devices can handle all of this internally. TT-6400 cards, for example, even continue to display live TV while the computer is rebooting. The general way to switch to a channel is: - cDevice::PrimaryDevice()->SwitchChannel(channel, LiveView) Instruct the primary device to switch to a channel - cDevice::SetChannel(Channel, LiveView) Actually handles the switch - cDevice::GetDevice(Channel, Priority, LiveView, Query) Picks the device that will be receiving. Tries hard to prefer the primary device (output device) as source device too. If receiving device is an other than the output device, a transfer control / transfer device is created to link them. One more thing to be aware of: Old non-HD FF cards can only either receive or directly display a video stream. If you watch and record a stream, the recording will usually be on a different device, so two devices will tune to that channel. If there is no other device, and both need to use the same receiving device, then live viewing has to be done using transfer mode. (might break on high bandwidth channels.) I'm not completely sure where in the code this is handled, though. AFAIK the TT6400 cards technically can record and display at the same time, but I'm also not sure whether this is already implemented or still handled the 'old' way. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.27 : compilation error with several plugins
Am 01.05.2012 14:00, schrieb Karim Afifi: > Hello, > > I am building a new box with vdr-1.7.27. Several plugins don't compil > anymore with this error msg : > i18n.h:8: error: ‘tI18nPhrase’ does not name a type > > Is there a solution to fix this ? Most plugins should have updated versions or developer snapshots available by now. Some patches are also available at vdr-portal.de. For the common iI18NPhrase bugs, there's usually a line missing in i18n.h: --- i18n.h +++ i18n.h @@ -9,6 +9,7 @@ #ifndef __SOMEPLUGIN_I18N_H #define __SOMEPLUGIN_I18N_H +#include #include #if VDRVERSNUM < 10507 Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.28
> > timers.c: In constructor ‘cSortedTimers::cSortedTimers()’:
> > timers.c:832: error: class ‘cSortedTimers’ does not have any field
> named
> > ‘cVector’
>
> I don't get such an error message here.
May be a compiler dependent problem. The attached patch makes it work for me.
Cheers,
Udo
--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
--- a/timers.c 2012-06-03 14:48:59.0 +0200
+++ b/timers.c 2012-06-03 14:49:35.0 +0200
@@ -829,7 +829,7 @@
}
cSortedTimers::cSortedTimers(void)
-:cVector(Timers.Count())
+:cVector(Timers.Count())
{
for (const cTimer *Timer = Timers.First(); Timer; Timer = Timers.Next(Timer))
Append(Timer);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFE: Make VDR more friendly when using combinations of DVB-S, DVB-T and DVB-C
> Why not just patch VDR so it cycles through channels that use the same > channel number. No bothering with sql databases & dependency, no > altering the real channel numbers, no real pain that I can think of. > For example, say you have 3 different sources using the same channel > number: > > channel 100, dvb-s > channel 100, dvb-t > channel 100, dvb-c > > You tune channel 100 from your remote, it tunes 100 dvb-s. Press 100 > again and it tunes 100 dvb-t. And again, 100 dvb-c. And again, loop > back to 100 dvb-s. Also, instead of having to enter the channel number > to cycle through them, maybe just use different keys (skip +/-, > ffw/rew, some other keys) to cycle. If there's only one of that > channel number, the cycle keys don't do anything. I have a similar idea that I've carried in my head for some time. The idea is to extend the "channel number" by another character, like '.'. That way you can store the dvb-s channel as 100.1, the dvb-t as 100.2, and so on. Or if you have the same channel in HD and SD, give SD the 100.3. The channel number 100 would be an alias for one of the 100.x channels, ChUp/ChDown will go to 101 or 99 directly. Recordings for channel 100 will also pick the first available of them. By hitting a '.' key on the remote, you can still enter the sub level, where ChUp/ChDown cycles between 100.x channels, or for timers to record from a specific source. Hitting '.' again could return to the top level of numbers. Of course this would require a rewrite of the channel numbering code, probably by making the current channel numbers internal only, and having an additional UI channel number as string. For the channels.conf syntax, this could be an extension to the :@ syntax, where :@. or :@100. or @100.1 starts a group of channels. And maybe an empty :@ to end the group without explicitly setting :@101 as next number. Cheers, Udo -- Udo Richter mailto:udo_rich...@gmx.de (GPG/PGP avail.) http://www.udo-richter.de/ < Werbefläche zu vermieten > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Please share your systemd (Upstart) service file
> On 3 July 2012 07:51, Klaus Schmidinger wrote: > > > VDR (and me, too ;-) doesn't care in what way a particular system boots > > or starts its services. > > It would be handy though, if VDR proper came default with a way to > toggle plugins on and off in the user interface. It is nice, but as an additional option. But you absolutely need a way to enable/disable/configure plugins from the outside of VDR, in case that a plugin crashes on startup, an output plugin does not output in default configuration, remote is not working, or similar. runvdr-extreme for example can enable/disable plugins via menu, but you can also do it via a command line tool, or by setting/deleting rc?.d-like symbolic links. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR File splitting validation
Am 04.09.2012 15:22, schrieb Rares Pop: Now, when VDR does the file split (after the quota has been met and a video I-Frame is about to start) the audio packets that would be in sync with the latest video frames before the split are actually being contained in the next split file. Thats because VDR does splitting and editing on the data stream level, not on the audio/video-track level. Merging all the file pieces together always gives the original stream, with just very minor modifications. Editing based on time stamps would be a lot more difficult, as near the splitting point, data needs to be moved to the previous/next file, depending on whether audio is ahead/behind video. To make things more complicated, there's no guarantee that together with the I-frame also a new audio frame starts at the exact time stamp. For precise editing, an audio frame may have to be split and re-compressed. And for playback, the same applies in reverse: For pre-buffering, the A/V-data of the file end and beginning needs to be merged with proper offset again. This is all a lot more complicated than just splitting the whole data stream as one. For further processing, its the best to merge continuous stream parts into one big file, if the program cannot handle split files on its own. If you want to avoid the copying, take a look at vdrnfofs, a virtual file system that virtually merges VDR recordings into single mpg files. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR File splitting validation
Am 05.09.2012 11:13, schrieb Rares Pop: You were saying that VDR does splitting and editing on the data stream level, not on the audio/video-track level. Am I to understand that vdr doesn't make the files at the beginning of a video I-frame? The video stream gets split at a TS packet that contains an I-Frame / GOP start of the VPID video stream, thats true. But all other streams get split just at that same point in the data stream, not necessarily at any special boundaries. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-1.7.31 & small improvement for last viewed recording
Am 03.10.2012 10:36, schrieb AlexW: If no last viewed recording was set (mostly after restart of vdr) and you press the Play Button all Recordings will be shown. Nice idea. But I think the idea of having the play button have more functionality can be improved further. For one thing, a feature that I always wanted to implement, but never got to, is to remember the last playback across restarts, so you can easily stop watching, shut down, restart later, and just hit play to continue. Shouldn't be too difficult. Obviously, this would make your idea mostly useless. On a second thought however, VDR could react differently when reaching the end of a recording, compared to stopping in the middle. When played back to the end, hitting play would show the last 10 seconds again, something you probably don't want. Instead, VDR could show the recordings folder the recording was in, so you can for example pick the next following recording. Or if you really want to see that recording, just hit play again. I really like the idea of starting up VDR, hit play, and either continue to watch the last recording I've seen, or to start watching the next following recording. Thoughts on that? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
Am 30.09.2012 15:41, schrieb Klaus Schmidinger: - The new class cIoThrottle is used to allow I/O intense threads to temporarily suspend their activities in case buffers run full (suggested by Torsten Lang). Currently the cutter thread is suspended if the TS or Recorder buffer use more than 50% of their capacity. Plugin authors may want to participate in this mechanism if they use intense background I/O. I'd suggest to use this for the low disk space deleted recording cleanup too. Recently, I've seen an issue like this happen, using VDR-1.7.30, where my disk was nearly full, and some deleted recordings didn't get wiped before a new recording. After a while, two HD recordings running at that time, AssertFreeDiskSpace kicked in and cleaned a deleted recording to free up disk space, resulting in an buffer overflow for the recorder: 02:08:31 low disk space while recording, trying to remove a deleted recording... 02:08:31 removing recording /video/...del 02:08:31 removing /video/...del/1.ts [...] 02:08:37 removing /video/...del/00100.ts 02:08:37 removing /video/...del/resume 02:08:37 removing /video/...del/marks 02:08:37 removing /video/...del 02:08:38 max. latency time 7 seconds 02:08:43 buffer usage: 70% (tid=27204) 02:08:43 buffer usage: 80% (tid=27204) 02:08:44 buffer usage: 90% (tid=27204) 02:08:44 buffer usage: 100% (tid=27204) 02:08:44 ERROR: 1 ring buffer overflow (1 bytes dropped) 02:08:44 buffer usage: 70% (tid=27187) 02:08:44 buffer usage: 60% (tid=27187) 02:08:45 ERROR: skipped 187 bytes to sync on start of TS packet 02:08:45 ERROR: skipped 187 bytes to sync on start of TS packet 02:08:45 cNaluDumper: TS continuity offset 6 02:08:45 buffer usage: 0% (tid=27204) The deleting was surprisingly slow, probably because of the high disk fill and fragmentation. And for some reason, the overflow happened after the deleting. Not sure what caused the delay. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-1.7.31 & small improvement for last viewed recording
Am 03.10.2012 12:28, schrieb Klaus Schmidinger: Not really. If the last viewed recording has been deleted, this new functionality could still kick in The patch above just checks the string presence. It should also check whether the string is an existing recording then. Sounds way too complex for my taste. Not necessarily. One way: When hitting play, check whether LastReplay exists, is a recording, and check whether the replay index is far from the file end. If not, show recordings menu. Another way: When writing index->StoreResume() in dvbplayer, check for file end and set a flag remembering that. Maybe together with LastReplayed file. Then, when hitting play, check for that flag and show recordings menu instead. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
Am 03.10.2012 14:55, schrieb Klaus Schmidinger: Which file system are you using for your video directory? I recently switched from ext3 to ext4 and it does feel a little "snappier". Its an XFS disk, and it was surprisingly fast on deleting when it was fresh. Unfortunately, #>df -m /video Filesystem 1M-blocks Used Available Use% Mounted on /dev/mapper/lvm--disk-data 948568943016 5553 100% /mnt/data which is not a good use% to run any file system on long term. :( Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
I've been doing things with Make.config too, and would like it to be available again. My plugins usually followed this pattern: -include $(VDRDIR)/Make.global -include $(VDRDIR)/Make.config -include Make.config so you always had the chance to have optional control without patching makefiles. The global Make.config had lines like this: ifeq ($(PLUGIN),someplugin) ... endif to do build configuration for some plugins, or to force-off some warnings or fix certain compile issues, or even add distribution-specific quirks. (building for different debian releases from same source) So I'm in for a central method to do configuration, and not having to patch every plugin makefile and distribute several local Make.config files. Am 25.12.2012 21:07, schrieb Klaus Schmidinger: On 25.12.2012 20:47, Reinhard Nissl wrote: 1.) there is a need for a common make configuration file for both VDR and plugins. No, only for *plugins*! VDR itself will have nothing to do with this file! Should be ok to have an Make-plugin.config, as long as all vdr relevant options from Make.config get passed on into vdr.pc and can be re-read by the plugin. Directly accessing Make.config is way easier than reconstructing it, though. Speaking of all, I wonder whether some plugin out there used PREFIX or MANDIR, these are now off-limits. Oh, and by the way, with introducing $(CWD) some previously relative paths got hard coded, so moving these builds around or accessing them from different mount points might now be broken. For example, my default lib dir changed from ./PLUGINS/lib to /usr/src/pc/vdr/vdr-1.7.34/PLUGINS/lib, which only makes sense within a single virtual machine that cannot even run VDR at all. I'll have to add some overrides for that. Also, this needs some thoughts on compatibility, as I prefer to provide ONE source code package, no matter what VDR version it is for. I won't support X different plugin versions for Y different VDR versions. Don't make me choose between dropping pre-1.7.34 or post-1.7.33, you might not like the outcome. Right now, the old Makefiles luckily just do compile after all. I suggest to put the lines PLGCFG ?= /etc/vdr/plugins.conf -include $(PLGCFG) into each plugin's Makefile and that's it. Please, prettyprettyprettyplease NOT /etc. Source code should compile from within its source folder, and not interfere with global configuration. I don't want to sudo scripts that prepare sources for compiling, and I want multiple source codes in parallel to build independently, without swapping files in /etc each time. Am 26.12.2012 15:54, schrieb Manuel Reimer: then just add your options to your "Make.config" as you did in the past, but prefix them with an "export ". Something like: export PLUGIN_OPTION = "any_value" This way the options reach the plugin Makefiles if you do your "make plugins" as the global VDR Makefile exports the value. Especially for development, make plugins is waaay to heavyweight. Until now it was easily possible to enter the plugin source directory and just do an make all. (for my plugins, even a simple make will do.) Your suggestion depends on passing through VDR's makefile first to realize these options. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.34
Am 24.12.2012 10:39, schrieb Klaus Schmidinger: - The plugin Makefiles now have a separate 'install' target (suggested by Christopher Reimer). In order to still allow the normal building of VDR (with all plugins in its ./PLUGINS/src subdirectory, the plugin libraries in ./PLUGINS/lib and the i18n files in ./locale) the VDR Makefile checks the settings of LIBDIR and LOCDIR when building the plugins from within the VDR source directory. If these macros have their default values, then the 'install' targets of the plugins' Makefiles are called. Otherwise the 'all' targets are called and the plugins are merely built, and will have to be installed by a call to 'make install-plugins'. This now also allows a user to copy a plugin source to any directory, change into that directory and do 'make' and 'make install' to have the plugin installed to wherever the local installation of VDR expects them. This has a major downside: LIBDIR and LOCDIR have two different meanings: First, the install target for make install, second, the default search path for VDR as long as --lib and --localedir is not specified. There's no way to handle them different. So either I have a build that expects ./PLUGINS/lib to exist, or I *have* to use make install, that currently creates a total mess. (xineliboutput even tries to write outside of DESTDIR, and luckily fails to write directly to /lib/.) I'm now (after 6 hours) at the point that I'll probably have to write an own lib and locale collector script that collects what has been in ./locale and ./PLUGINS/lib before, avoiding all the Makefiles, picking the right folders and files (there's no common way to find the .so file in the src folder), renaming them, etc. And I'm starting to think whether staying at VDR-1.7.33 wouldn't be the better solution. (or returning to 1.7.31 where editing recordings doesn't take forever.) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.34
Am 27.12.2012 14:43, schrieb Klaus Schmidinger: If you want to use your "hardlink cutter" with recent versions of VDR, you could simply patch out the calls to DanglingPacketStripper.Process(), GetPendingPackets() and ptsFixer.Fix() in cCuttingThread::ProcessSequence(). There will be no fixing of timestamps and continuity counters then, but I guess you don't need that, anyway... Its probably a bit more tricky than that, as the exact definition of editing marks has changed. (eg. two marks at same place, including the ending GOP, etc.) It needs a proper rewrite from scratch to get at least the old style back, and my time is way to limited. A pragmatic quick-hack I've thought of was to set up a recording command that launches an old VDR version's command line editing call. It also handles editing marks the old style though. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 28.12.2012 09:28, schrieb Klaus Schmidinger: Well, if a plugin is no longer actively maintained, it's probably time to drop it. You know what they say about dead horses ;-). Being actively developed and being needed are two different things. I wouldn't want to drop all the plugins that aren't under active development any more, as this would probably be true for 2/3 of my plugins. If you put all your plugins into PLUGINS/src under the VDR source directory (with the old Make.global still in place), change into PLUGINS/src and do for i in *; do make -C $i all; done I would guess that they build regardless whether they use an old or new Makefile. Maybe you should give it a try. Nope, as you forgot to filter out folders with version numbers. Plus, any updated plugin (at least any built-in plugin) does no longer create the *.so.$APIVERSION file, and there's no generic way to do this. All updated plugins require an additional make install, that will create the *.so.$APIVERSION in some folder defined in vdr.pc. However, some old-style plugins will do totally different things on make install, like xineliboutput for example. Thats why I wasn't even able to set up a running test build of my VDR yet, even though it complied without any issues: Total mess of .so files. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 28.12.2012 09:29, schrieb Klaus Schmidinger: On 28.12.2012 00:47, Dominic Evans wrote: IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON Not breaking userspace is, of course, the right thing to do in a *stable* version of any software. In Linux context, it actually means keep compatibility to any userspace app across as many generations of stable releases as possible. It means for example, that any program written and compiled against the DVBv3 API still works, and will work for several years on, even though DVBv5 is so much better. For plugin developers it means, don't demand that the user has to use a certain VDR version. If plugin foo only works with VDR-1.7.xy, and plugin bar requires VDR-1.7.ab, the user looses. Good plugins should work with any version at least back to the last stable release. And the recent changes didn't make things easier. Right now I'm in the awkward situation that I cannot port my plugins to .34 because for serious tests I need ported versions of several other plugins. Its a chicken-and-egg thing, and right now all the eggs are broken. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 28.12.2012 14:37, schrieb Klaus Schmidinger: On 28.12.2012 14:19, Udo Richter wrote: Plus, any updated plugin (at least any built-in plugin) does no longer create the *.so.$APIVERSION file, and there's no generic way to do this. Well, then maybe this works (haven't tested it): for i in *; do make -C $i all; cp $i/libvdr-$i.so ../../PLUGINS/lib/libvdr-$i.so.1.7.34; done As I said, no generic way to do this. For example: epgsearch/libvdr-conflictcheckonly.so epgsearch/libvdr-quickepgsearch.so epgsearch/libvdr-epgsearchonly.so epgsearch/libvdr-epgsearch.so streamdev/client/libvdr-streamdev-client.so streamdev/server/libvdr-streamdev-server.so servicedemo/libvdr-svccli.so servicedemo/libvdr-svcsvr.so xineliboutput/libxineliboutput-fbfe.so.1.0.90-cvs xineliboutput/libvdr-xineliboutput.so.1.7.34 xineliboutput/libxineliboutput-sxfe.so.1.0.90-cvs Different locations, different file names, sometimes multiple files, sometimes other .so files that are not needed. Until now, "make all" did that magic, and lots of plugins did it their way. Now there is no way to get all needed files except running "make install". ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 28.12.2012 16:38, schrieb Klaus Schmidinger: > So should we go back to the Makefiles of version 1.7.33 and declare this > area of the program source "untouchable" forever? Beside all the current whining (and *I* don't exclude myself from that), it is nevertheless a step in the right direction. Just returning to the old system wouldn't solve any of the basic problems that this change addressed. Things that could have been handled better: - More discussion about the best strategy beforehand. Even if there was an thread in vdr-portal, I did miss it, and there was no word of it in the mailing list, which I always considered to be the central spot of development. Right now it leaves the impression that the new system was designed to make exactly two persons satisfied for their needs. - Some smooth transition strategy. At least for some versions being able to use the old and new makefile system would help a lot. That was actually the next trick I wanted to check, whether there's a safe way to grep for old vs. new system and handle them differently: Old system would just make all, and instead of make install copy from the old folders, while new system passes make all and make install to the plugin. Another improvement would be a way to explicitly tell the plugin that its being build in the source tree, and that ../../lib etc. should be a target, but that needs to be supported by all the plugins. - Some compatibility strategy. Being able to build the same plugin source under several VDR versions helps plugin developers a lot. Though this is not VDR's concern, it helps to keep that in mind. So all in all, lets just look forward, not backward, and find ways to improve the system. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 30.12.2012 01:08, schrieb Christopher Reimer: 2012/12/29 Udo Richter : Even if there was an thread in vdr-portal, I did miss it, and there was no word of it in the mailing list, which I always considered to be the central spot of development. Really? http://linuxtv.org/pipermail/vdr/2012-November/026813.html There was NO answer at all. That was about a redundancy in Make.config and Make.global, and concludes to swap the include order of them. There's no word in it on dropping Make.config completely, and no word on introducing new mandatory make install targets or redefining the existing make all. I wonder why I didn't see that coming. ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Permissions in vdr-1.7.35 tarball
Am 05.01.2013 13:16, schrieb Klaus Schmidinger: Looks like this was caused by an NFS problem on my system. Will be OK again in the next version. While on packaging, you might want to check for some empty folders that get packaged. Last version had a locale/ tree and a PLUGINS/src/dvbhddevice/locale/ tree with just folders, no files. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Call for development: enhancing mplayer-plugin
Am 27.02.2013 11:56, schrieb Peter Münster: > Support for seeing the VDR osd over mplayer doesn't exist yet. > > Who could add this feature please? And what would be the price? Basically, the OSD-over-mplayer does work for dvbsddevice and other devices that mplayer supports. Also, there was already an attempt to get mplayer plugin working for TT6400/dvbhddevice cards, but it got stuck a long time ago: http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/105796-mplayer-und-tt-6400/?s=2f9ffc972e8fbfd8b390e5dfb1a6abe95cf80963 One thing the thread has is a generic solution for the need to mix OSD and video stream: There's a modified version of mplayer plugin that moves this part where it belongs, back into VDR. Instead of VDR closing the video device for mplayer while keeping the OSD open, VDR takes over a stream from mplayer and forwards it to the proper output device, whichever that is. Problem however is that the old stream output feature of mplayer is suffering from bit rot, and isn't working very well. Plus, the TT6400 didn't like the mplayer encoded stream. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Call for development: enhancing mplayer-plugin
Am 27.02.2013 22:16, schrieb VDR User: > Is there any hope that this could be resurrected? Also, what about > those of us who use VDPAU? Its more a thing for hardware decoder cards that cannot handle an uncompressed video stream, as it always re-encodes to some fixed output format, eg. mpeg1/2. The mplayer plugin modification should be ressurectable, with some updates to plugin structure. It basically expects a video stream that can be handled by the output device delivered via unix pipe. However, the mplayer playback-recode-to-file feature is quite broken, and currently needs some ugly workarounds. And of course, its still uncertain why the TT6400 denies playback of mplayer encoded video. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] read-only video directory
Am 05.03.2013 10:35, schrieb Peter Münster: > How is it possible, to mount the video directory in read-only mode? > I want to use a slave vdr like this: > vdr -Pstreamdev-client -Pxineliboutput -v/net/media/data/video > But it does not work, because /net/media/data is mounted read-only. > The slave vdr should not write anything, just read the recordings. You can always mount an unionfs or aufs on top of the read only mount, and redirect all write access to a local disk or ram disk. That way VDR will be able to write its status files without changing the source file system. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] read-only video directory
Am 06.03.2013 21:56, schrieb Peter Münster: > On Wed, Mar 06 2013, Stephan Loescher wrote: > On Wed, Mar 06 2013, Udo Richter wrote: >> You can always mount an unionfs or aufs on top of the read only mount, >> and redirect all write access to a local disk or ram disk. That way VDR >> will be able to write its status files without changing the source file >> system. > > Hi Stephan and Udo, > > Unfortunately I don't understand. Could you please show examples? > > I have for example this directory: > /net/media/data/video/Pippi-geht-von-Bord/2010-07-31.06.55.50.99.rec Just improvising, haven't tested it, but should give you a hint how to do it: - assuming /net/media is an NFS mount or similar - create a folder /net/media-tmp (optionally mount an tmpfs on it) - create a folder /net/media-rw - mount -t aufs -o br:/net/media-tmp:/net/media aufs /net/media-rw Now you have a virtual copy of /net/media in /net/media-rw, fully writeable, where all write access goes to /net/media-tmp instead, leaving /net/media untouched. You can play back /net/media-rw/data/video/Pippi-geht-von-Bord/2010-07-31.06.55.50.99.rec just as before, you can even delete it, but the recording will only disappear within /net/media-rw, the original copy in /net/media stays untouched. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] read-only video directory
Am 08.03.2013 19:35, schrieb Stephan Loescher: > When you use the suggested solution with unionfs, then the client uses > the servers setup/timers/epg/etc. because it sees them in its > /video-directory. Only until the first write, after that the client will continue with its local writable copy. It is generally possible (and in a network shared environment also a good idea) to have config files in a different place, and just recordings within /video. If you definitely want shared (read-only) config files, I'd suggest using symbolic links, like /etc/vdr/channels.conf -> /net/media/data/vdr-config/channels.conf. Solves a lot of problems, like clients trying to record the same as the server because of same timers.conf, or not having to configure streamdev-client on the server. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.41: what's new way to run vdr out of it's sourcedir?
Am 17.03.2013 09:51, schrieb Lars Hanisch: > Am 17.03.2013 09:20, schrieb Halim Sahin: >> vdr doesn't copy plugins to PLUGINS/lib. >> Is there a way to get the old behaviour back? > > I think "make LCLBLD=1" should do it. Mostly, but YMMV. Some plugins may not support it. >From my builds yesterday, the most recent xineliboutput Makefile seems stuck between the versions, not copying 'the old way' to ../../../PLUGINS/lib any more, and not adhering 'the new way' LCLBLD request to do it. Also, in case ./PLUGINS/lib is not the final destination, you'll loose the ability to set default search paths for all the libs, so you have to specify them on command line. The alternative, doing an "make install DESTDIR=/tmp/foo/" and picking files from there may fail because of too many broken plugin Makefiles. (at least the last time I've tried) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Channel update on HD transponders broken?
Hi list, I've noticed that I don't get channel updates any more on most of the German HD transponders, since my update from 1.7.37 to 1.7.41 on 2013-03-16. I'm running VDR in "add new transponders" full update mode. I didn't check 1.7.42 yet, sorry. I'm running a very minimal old patch that tracks the time of the last channel update, so I'm pretty sure that the channel update stopped exactly at 2013-03-16 for all channels on the following 19.2E transponders: 10773 (ANIXE HD/BetaDigital), 10802 (ASTRA 3D Demo/BetaDigital), 11082 (RTL HD Austria), 11170 (OrangeSAT), 11302 (ORF1 HD), 11332 (Syfy HD/SKY), 11361 (ZDF HD), 11464 (ProSieben HD), 11493 (Das Erste HD). All other transponders get updated normally. To check whether channel update works, try to edit the channel name of Das Erste HD. Channel update should restore the original name almost instantly. First, can someone reproduce this with their VDR? I don't want to stop the presses unnecessarily. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel update on HD transponders broken?
Am 31.03.2013 09:08, schrieb Oliver Endriss: > Udo Richter wrote: >> I've noticed that I don't get channel updates any more on most of the >> German HD transponders, since my update from 1.7.37 to 1.7.41 on >> 2013-03-16. > > Could you test whether the patch in the VDR portal post > http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1135671-gelöst-keine-epg-anzeige-für-das-erste-hd-zdf-hd-und-ndr-mv-hd-nach-wechsel-von-1-7-29-auf-1-7-42/#post1135671 > fixes your problem? AARGH! Thank you for slapping that into my face, I even helped fnu analyzing this problem when using s2apiwrapper light on old kernels, but thought, hey, you're using powarman's v4l-dvb branch on the runtime machine, luckily this can't hurt you. Unluckily, powarman's branch is still DVBAPI 5.2. *facepalm* /)_~ Well, I guess I have to fix that in s2apiwrapper light after all. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] S2API Wrapper Light 0.10 for VDR-2.0
Hi, I've uploaded the newest version of S2API Wrapper 'light', the wrapper patch to VDR that ensures DVB API compatibility to all DVB 5.0 API kernel headers. The new version fixes the DVB-S2 EPG bug that was introduced with 1.7.40, whenever the runtime kernel had DVB API 5.7 or less. To do so, the wrapper queries the API version of the running kernel, and switches to legacy code depending on that. At the same time, some of the VDR compile-time code switches depending on DVB API version of the kernel/driver headers were converted to runtime kernel switches. All in all, with the patch VDR should compile on all DVB header versions from 5.0 upwards, and all DVB features should be available as long as the runtime kernel supports them. Get it here: http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR version 2.0.0 released
Sorry for interrupting the party, great job for sure, but I think EPG on DVB-S2 is in fact buggy on DVB APIs 5.3 to 5.7. For these API verisons, the API 5.8 code fork replaces DTV_STREAM_ID with DTV_DVBT2_PLP_ID, and sends this command to DVB-S2 cards, even though DVB-S2 cards can hardly handle DVB-T2 commands. At least DVBAPI 5.2 will fail miserably on that, not sure if DVBAPI 5.3 to 5.7 is more tolerant in ignoring this. Suggested fix is to at least limit the DTV_STREAM_ID call for DVB-S2 to DVB API 5.8. Alternatively, you can take over my runtime check, or just drop support for DVB API 5.7 and older. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] TT6400 dvbhddevice ScaleVideo aspect ratio correction
Am 05.04.2013 19:37, schrieb Lucian Muresan:
> I wrote a patch for the ScaleVideo implementation in the dvbhddevice,
> for keeping the actual aspect ratio of the video material when scaling.
My initial thought on the code was that it seemed to unnecessary do too
many double to int conversions, plus not doing any of them with proper
rounding. But I also thought, this might turn out simpler when
transforming it a bit. So I just did some math transforms, and it came
out quite embarrassingly simple:
// Scale to units of 1/1000 osd, with rounding
int x = (Rect.X() * 1000 + osdWidth / 2) / osdWidth;
int y = (Rect.Y() * 1000 + osdHeight / 2) / osdHeight;
int w = (Rect.Width() * 1000 + osdWidth / 2) / osdWidth;
int h = (Rect.Height() * 1000 + osdHeight / 2) / osdHeight;
// make aspect corrections
if (w > h) {
x += (w - h) / 2;
w = h;
}
else if (w < h) {
y += (h - w) / 2;
h = w;
}
mHdffCmdIf->CmdAvSetVideoWindow(0, true, x, y, w, h);
This should be functionally identical to the original code, except for
less rounding errors. I haven't tested it though.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems with VDSB, how to automate in SYSLOG
Am 27.04.2013 10:50, schrieb Brian-Imap: > Hi, > on some channels I get Video Data Stream Broken messages, not sure quite > what triggers them yet. VDSB is triggered if a recording doesn't receive any video data within 30 seconds. Usually this is because either the channel doesn't exist / doesn't broadcast, or because the DVB hardware failed and stopped working. If you disable emergency exit, VDR will likely continue to see no data, so forget about that recording. > I know I could extend the VDR start script to unload/load the DVB > drivers after a VDR exit too. This is the only thing that might cure a VDSB, and the only reason to do an emergency exit at all. Its quite unlikely that restarting VDR without reloading drivers will make any difference. (though not impossible, I've seen strange crosstalk effects in the past, and VDR doing something completely different after restart sometimes helped.) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems with VDSB, how to automate in SYSLOG
Am 27.04.2013 14:06, schrieb Brian-Imap: > The single one at the start is what stops me activating the emergency > exit in VDR. Do you have an in-accurate system clock and/or clock syncing enabled? VDR will falsely trigger an VDSB if the clock is set more than 30 seconds ahead while a recording is running. If you set the clock by DVB time, I'd suggest restricting it to one channel only. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems with VDSB, how to automate in SYSLOG
Am 28.04.2013 16:52, schrieb Brian-Imap: > So you assume it was falsely triggering a VDSB thinking 30 secs had > passed when in fact the clock probably was adjusted instead? Its the only false alarm I know of, and would be an explanation why this happens on the start of a recording. Tuning to the channel for recording may activate the clock sync for that transponder, and cause a time jump once. All other explanations involve crappy driver/hardware or bad reception. There should be a log message indicating the clock sync. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR wird in 3:00 Minuten ausschalten
Am 13.10.2013 18:20, schrieb Torsten Mohr: > i have installed an /etc/vdr/shutdown.sh which will NOT shutdown as long as > somebody is still logged in. > > So i know pretty sure that VDR is NOT going to shutdown. > > The message shown "VDR wird in 3:00 Minuten ausschalten" does not make > sense on my system. If I understand you correctly, then the system will shut down once there is no logged in user. In this situation, the message does make sense, and it would be awkward if VDR shuts down after the last user logs off without any further warning. VDR doesn't know much about what might have stopped shutdown externally, so the only way is to frequently retry. And since VDR never knows if shutdown will succeed, until the final termiante call, there needs to be a warning beforehand. After all, since there was no interactive usage for a long time, its very unlikely that there's someone actually seeing the shutdown messages pop up every few minutes. There's a more complex plugin interface to shutdown, where even the shutdown message can be suppressed while busy, but there's no easy way to extend this to external scripts. One could however write a plugin that provides more complex interaction with external scripts, like ask for shutdown, and accepting something like "wait for 5 more minutes" in return, without displaying messages. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR wird in 3:00 Minuten ausschalten
Am 15.10.2013 00:48, schrieb Lars Hanisch: > Wouldn't a "MinUserInactivity = 0" disable the message because the user > never gets inactive? It would, but in that case the automatic shutdown would be disabled too. In that case, hitting the power button is required to get inactive, resulting in the same frequent shutdown retries as before. @Torsten: Regarding the original problem, to what value is your MinUserInactivity option set? If you did set that to a very small value, you're probably trying to get around an automatic shutdown issue the wrong way. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR wird in 3:00 Minuten ausschalten
Am 17.10.2013 19:09, schrieb Torsten Mohr: > If nothing happens and nobody is logged in i shut down the VDR after 30 > minutes. So a value of 180 would prevent a shutdown after 30 minutes of > inactivity? Yes and no. It depends on whether VDR thinks there's someone watching, in that case VDR shuts down after 3 hours, or not, causing VDR to shut down after 6 minutes. Three ways(*) lead to VDR believing that no one is watching: First, not hitting a key for 3 hours, second, hitting the power key while recording or other internal things that don't allow for instant shutdown, or third, starting VDR close to a scheduled timer event. As long as VDR thinks no one is watching, and nothing important is scheduled soon, VDR tries to shut down every 6 minutes. (*) Actually, there's a fourth, hackish way: Write the current epoch time into setup.conf as NextWakeupTime, before VDR starts. Just in case you do know that VDR was started somehow automatically. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3
Am 06.01.2014 09:59, schrieb Reinhard Nissl: > But this still seems error prone -- looks like a more complex solution > is needed which keeps track of how often a transponder has been seen > dead over a certain period of time before declaring these channels > OBSOLETE (and later delete them automatically). > > I don't know if it is worth to extend the file format of channels.conf > for that tracking, but at least in memory VDR could keep track of that, > starting from scratch whenever VDR is restarted. I have a little patch running doing exactly this, the patch just tracks the last-seen timestamp within the running session, or the state 'not seen in this session'. Load/save is not implemented, everything gets reset at program start. Its a whopping 8-lines patch. This is accompanied by a plugin that extends the last-seen time by syncing with the patch data from time to time, and keep the time together with the channel ID persistently stored in a separate file. If a channel wasn't announced for a month, it gets marked as gone. However, this doesn't differentiate why a channel wasn't seen, for example because the machine was off for a longer time, or the required receiver isn't connected. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Invalid sat cable number errors
Am 17.04.2014 22:28, schrieb Ville Skyttä: > On Thu, Apr 17, 2014 at 6:57 PM, Alexander Kniwel > wrote: >> Hi, >> >> I had exactly the same errors on my VDR (2.1.6): >> >> ERROR: invalid sat cable number in '°$Q‘ >> >> In my case the „binary junk“ is always °$Q, and the message appears also in >> a 30 min interval. >> >> After deactivating/removing the naludump patch, I can’t find the messages in >> the logs anymore. But this is just a guess and I don’t know if this is >> really related…. > > Bingo, same thing here. Rebuilding VDR without the NALU dump patch > gets rid of the error -- if the patch is in, it doesn't seem to make a > difference if it's enabled in settings or not, the error is always > there in syslog. Cc'ing patch author (@Udo: see below). Hmmm, thats weired. I don't have such errors on my system, and even more strange, minimizing risks was one of the design goals of the patch, thats why the nalu filter is right before the disk writer, thus without an ongoing recording, the patch does nothing. The filter itself also makes sure that no data can be accidentally dropped, by only dropping TS packets that only contain FF bytes and only within nalu fill packets. Is this the original patch from my website? ( http://www.udo-richter.de/vdr/naludump.html ) Are there any hints that this behavior started with a certain VDR version? Ok, some leaning out of the window: The patch adds an entry to config.h. The message origins from the config.h string DeviceBondings. Maybe not all parts of VDR (or plugins) were compiled against the patched config.h? This would cause an mis-aligned access to the string. Cheers, Udo PS: Unfortunately, I'm offline for two weeks, starting Friday. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Forced boot once a day
Am 14.09.2014 12:02, schrieb Thomas Maaß: > Maybe an option could be added to VDR to force a boot once a > day. When the next timer is later than a specific time, set the > wakeup time to this time. You could hack this into the shutdown script itself. Tomorrow=$(($(date +%s)+86400)) would be the time in exactly 24 hours, and in the same epoch format as the $1 parameter of the shutdown script. So if $1 equals 0, or $Tomorrow is less than $1, use $Tomorrow instead. For completeness, you can also tell VDR that this is the actual expected boot time, by modifying setup.conf *after* VDR terminated: sed -i -e "s/^NextWakeupTime = .*/NextWakeupTime = $Tomorrow/" setup.conf That way, VDR will wake up with no timer nearby, and as it just don't know what went wrong, it'll shut down again 6 minutes later. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Forced boot once a day
Am 17.09.2014 20:44, schrieb Thomas Maaß: > How can I compare the wakeup times in a bash script? A "0" is given when no > timer is present? Basically, something like this: boottime="$1" if [ "$1" -eq 0 -o "$1" -gt "$tomorrow" ] ; then boottime="$tomorrow" fi After that, use $boottime instead of $1 for wakeup programming. Untested, ymmv. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years of VDR!
Thanks, for changing my TV viewing habits 13 years ago, and for keeping it running for all these years. Keeping that continuity for that long time is quite impressive. Now, where do I find that time to upgrade my machines... But first, party! (\ ^.^ /) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR findet S13E nicht mehr nach Upgrade
On 30.04.20 17:46, Harald Milz wrote: Nach längerem habe ich mich endlich aufgerafft, Wenn man plötzlich Zeit hat, und never-touch-a-running-system neu aufsetzt... woher kenn ich das? ^^ Ich hätte erwartet, dass er dafür frontend 2/0 oder 3/0 verwendet. Auf denen wirft er aber ständig Timeouts zu Channels von S19.2E. Ich hab kein so kompliziertes Setup, deswegen generische Tipps: Ich würd erst mal versuchen, die Konfiguration auf die Frontends 3 und 4 einzuschränken und ohne Doppelsetup nur testen, ob Hotbird überhaupt will. Wenn das geht, was passiert, wenn man Astra auf 3,4 und Hotbird auf 1,2 legt? So kann man das Problem schon mal rein auf Software eingrenzen. Gruß, Udo ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR packages in Debian and e-tobi.net
On 13.12.21 00:28, Tobi wrote: I hope to have at least have the top 20 plugin packages updated by the end of the year. If you need help with any of my old plugins or patches, let me know. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
