Well, I would actually prefer it built in to vdr. Heck, I'd prefer that vdr's on screen EPG was as nice as yaepgs. I suggested the reminder belong in a plugin because the record timer in yaepg is more advanced / user friendly than the one built in to vdr. I may be mistaken on this--I am new to vdr and linux-- but I thought that yaepg was using its own timer features and not simply providing a nice front end GUI for a vdr function, and it also seems most people use a plugin such as yaepg. However, I agree it would be beneficial for this to be a part of vdr. So if yaepg is simply "calling" vdr's record timer when you go to a program and click "OK" to schedule a recording, then it should be fixed in vdr. But I also know that Klaus is busy with many other planned features, and that vdr, while usable on a clean install, really needs lots of plugins to make it work more like a set top box. I too was surprised there was no reminder. I am also surprised at the poor search epg features, as these seem basic and easy to implement.

It makes absolutely no sense for a reminder feature to be done via plugin. This is a very common and basic feature offered in most dvb-c and dvb-s receivers. Honestly, I was surprised to find out vdr didn't already have it implemented because it -is- such a basic function. Logically I don't see it anywhere else other than the core code. I'm not sure why you mention yaepg as that's just an alternate means to view guide data. Yaepg has nothing to do with timer functionality or reminders. Maybe you could elaborate more on how you came to your opinion on this?

On 2/2/07, martin martin@air-maxx.net wrote:

You should have a look at the BigPatch. It has some "switch timer" included.

It sounds like we can just extract this feature out of the "BigPatch". Has anyone tried that? The entire "BigPatch" sounds a little scary, but I too would like to try the one feature from it. :)

Regards.

martin wrote:

To be honest, i use BigPatch for just one reason. During playback, I can jump 10 sec + / - with the “1” and “3” keys. I can’t live without this feature, because jumping 1 Minute is nice, but most of the times way too long. So, actually, adding this 10 seconds jump to the main part, would also help me a lot!

Why don't you just press FFWD/FREW shortly?

PS: I changed the subject to the eMail, beause we have opened a new topic here.

Actually you should have started a new thread!

Klaus

On 2/2/07, martin martin@air-maxx.net wrote:

To be honest, i use BigPatch for just one reason. During playback, I can jump 10 sec + / - with the "1" and "3" keys. I can't live without this feature, because jumping 1 Minute is nice, but most of the times way too long. So, actually, adding this 10 seconds jump to the main part, would also help me a lot!

Maybe Klaus will let the skip-time be user-definable in a future version, or maybe someone has already made a patch for it but for now why not just make your own small patch for it rather than apply BigPatch? I believe these are the lines in menu.c to modify:

case kGreen: SkipSeconds(-60); break; case kYellow: SkipSeconds( 60); break;

I've found the actual patch that is used in BigPatch in case you want just that. The thread is located at:

http://www.vdr-portal.de/board/thread.php?postid=68566

and the patch:

http://www.vdr-portal.de/board/attachment.php?attachmentid=1349

Hey Laz,

you speak from y hart! Exactly - there are some rules behind commercial brakes. This also applies to Germany as the media law regulates how many, how often, how long and so. I still use "noad" to detect the breaks. This works in most cases, but our RTL knows how to trick it. So "jump forward 1 minute, step back -10 sec, maybe two times" and there we go. It's the same rule that applies to the Internet. Everything just 3 clicks away - very handy, I would say.

Maybe there are more people out there that would this support this feature, as keys "1" and "3" are anyways not assigned during playback.

Regards, Martin

-----Ursprüngliche Nachricht----- Von: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Im Auftrag von Laz Gesendet: Sonntag, 4. Februar 2007 09:56 An: VDR Mailing List Betreff: Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

On Saturday 03 February 2007 18:03, VDR User wrote:

On 2/2/07, martin martin@air-maxx.net wrote:

...

To be honest, i use BigPatch for just one reason. During playback, I

can

...

jump 10 sec + / - with the "1" and "3" keys. I can't live without this feature, because jumping 1 Minute is nice, but most of the times way too long. So, actually, adding this 10 seconds jump to the main part, would also help me a lot!

Maybe Klaus will let the skip-time be user-definable in a future version, or maybe someone has already made a patch for it but for now why not just make your own small patch for it rather than apply BigPatch? I believe these are the lines in menu.c to modify:

case kGreen:   SkipSeconds(-60); break;
case kYellow:  SkipSeconds( 60); break;

I always copy the relevant lines for kGreen and kYellow (near the end of menu.c), rename them to k1 and k3, and change the delay to 10 s, leaving Green and Yellow to stay as 1 min skip.

The majority of advert breaks in the UK (on terrestrial channels) seem to be

about 4 minutes (I've got another key set to skip 4 minutes forwards...) but

some are +/- 10 or 20 s and being able to skip 10 s is very handy for me.

Cheers,

Laz

_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Rolf Ahrenberg wrote:

On Sun, 4 Feb 2007, Laz wrote:

...

I always copy the relevant lines for kGreen and kYellow (near the end of menu.c), rename them to k1 and k3, and change the delay to 10 s, leaving Green and Yellow to stay as 1 min skip.

You could always google this patch: vdr-1.4.2-k1_k3_Jumps_20s.patch

It has been included in my Liemikuutio and I've requested the similar feature to be integrated into vanilla VDR, but Klaus did disagree due to used key mapping.

Well, wouldn't the solution here be configurable jump length. Forward and backward jump separated so that 1min forward and 10s backward jumps are possible. This way most of the users would be happy.

One possibility would be to provide a command for this that can be defined in remote control configuration e.g.

<button> <command> <parameter>

commands: jump parameter: +/- num of seconds

This way any number of keys can be used for this so everyone will be happy (?).

Br, Pasi

Rolf Ahrenberg wrote:

On Sun, 4 Feb 2007, Pasi Juppo wrote:

...

Well, wouldn't the solution here be configurable jump length. Forward and backward jump separated so that 1min forward and 10s backward jumps are possible. This way most of the users would be happy.

Well, adding more of those configuration options just confuses most of the users, so I'd say no-no to this approach. However, if we cannot assing new keys, we could modify the behavious of current ones. If the key is repeated fast enough (<1s) the jump would be bigger than the previous (+10s -> +20s -> +30s -> +60s). In this way user could easily control the amount of skipping by pressing green/yellow buttons in different intervals.

When the default configuration is the same as it has been then it won't confuse any user. This configuration can be put to the last configuration so that it is basically "hidden". And then there are Man-pages so no, I don't agree that this would confuse users one bit. This is not something that needs to be changes constantly..

If this is done via remote control commands then it is not even shown to the user. If user cannot configure remote control then (s)he most likely is not using VDR anyway.

Accelarated repeating is very difficult for user to understand without time bar. Even with that it is very unconvenient because after a short while the step will be too long thus skips way too far. Rewinding takes longer because it begins with small steps. E.g. when I use jumping I usually press yellow several times fast and if necessary then go once or twice back and fast forward the rest. Acceleated jumping would cause the commercials to be skipped more slowly (in my case).

Br, Pasi

On 2/1/07, Michael Brueckner mb+vdr@mittelstation.de wrote:

Am Donnerstag 01 Februar 2007 23:42 schrieb abbe normal:

...

wondering if there is a way from the timers menu to only select to record or not record a program. what im wanting to do is set a timer to watch a program but not have vdr record it... not sure but just thinking it would be nice to have a option in the menu to not record but still go to the program...

Or use the epgsearch-Plugin and the "Switch list".

Michi

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

why would you want this as a plugin it is a timer issue if done in the vdr timers setup then it will work with all plugins i would think... i maybe wrong but just thinking its would be a good item to have...

On 2/3/07, Reinhard Walter Buchner rw.buchner@freenet.de wrote:

Actually my Nessy Patch already did this years ag :o)). Selecting the "View Only" mode created a special timer. As soon as the timer time was reached it let VDR switch to that channel. No recording was started and the timer was deleted as soon as the "switch to" channel was properly tuned to.

regards, Reinhard

Is your patch compatible with the latest stable (1.4.5*) and developer ( 1.5.0) versions? Could you please post it up, I'd love to have a look.

Thanks.

Hi there, im currently trying to write a Plugin that reads a DVB-TS-File from hard disk acting as a VDR input device. To do this i derived my own device from cDevice, reading the file into a TSBuffer and return it package wise in GetTSPacket. This somehow works. But the playback is only ok for 2 seconds, and after that it starts hanging and skipping and i get these "transfer buffer overflow" messages. It seems like the data from the file is provided too fast, because the parts that are skipped are much longer than the time playback is stuck. Also i can record from the device, and the resulting File is ok, but if the recording runs for 10 seconds i get a file that is 40 seconds long.

But shouldn't the rate at which the TS-packets are gathered from the input device be controlled by the output device?

I tried this on two systems, both without DVB hardware: 1: vdr-1.3.44, xine-plugin 0.7.9 2: vdr-1.4.4, xineliboutput-plugin 1.0.0pre5

--------------------------------------------------------------------------------------------------------

USER PID SPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 9118 9118 0.0 11.9 78228 61664 ? Sl 12:29 0:00 ./vdr -Px root 9118 9121 0.0 11.9 78228 61664 ? Sl 12:29 0:00 ./vdr -Px root 9118 9122 0.0 11.9 78228 61664 ? Sl 12:29 0:00 ./vdr -Px root 9118 9123 0.0 11.9 78228 61664 ? Sl 12:29 0:00 ./vdr -Px root 9118 9132 6.0 11.9 78228 61664 ? Sl 12:29 0:03 ./vdr -Px root 9118 9133 10.3 11.9 78228 61664 ? Sl 12:29 0:06 ./vdr -Px root 9118 9134 19.8 11.9 78228 61664 ? Rl 12:29 0:12 ./vdr -Px

Feb 2 12:29:06 linux vdr: [9132] transfer thread started (pid=9118, tid=9132) Feb 2 12:29:06 linux vdr: [9133] receiver on device 6 thread started (pid=9118, tid=9133) Feb 2 12:29:06 linux vdr: [9134] TS buffer on device 6 thread started (pid=9118, tid=9134) Feb 2 12:29:06 linux vdr: [9134] buffer usage: 90% (tid=9133) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 90% (tid=9132) Feb 2 12:29:06 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:06 linux vdr: [9132] clearing transfer buffer to avoid overflows Feb 2 12:29:06 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 90% (tid=9132) Feb 2 12:29:06 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:06 linux vdr: [9132] clearing transfer buffer to avoid overflows Feb 2 12:29:06 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:06 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:06 linux vdr: [9132] setting audio track to 33 (0) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 90% (tid=9132) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:07 linux vdr: [9132] clearing transfer buffer to avoid overflows Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 100% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] ERROR: 1 ring buffer overflow (177 bytes dropped) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133)

[...]

Feb 2 12:29:14 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 60% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:14 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:14 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 90% (tid=9132) Feb 2 12:29:14 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:14 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 100% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] ERROR: 166595 ring buffer overflows (31319794 bytes dropped

Marko Mäkelä wrote:

I've patched vdr twice so that it'd read the MPEG TS from a regular file instead of the /dev file system. The first time (about 2 years ago) on then-current vdr 1.3.x, it succeeded. The second time (maybe 1 year ago) failed with the symptoms you are reporting.

Do you remember how you patched it?

Maybe you could make cDevice::Transferring() return false, if it is a virtual method?

Tried that, but it deosn't have any effekt.

Reinhard Nissl wrote:

...

But shouldn't the rate at which the TS-packets are gathered from the input device be controlled by the output device?

But isn't it obvious that the output device cannot tell the TV station "stop broadcasting, I cannot cope with the data flow"?

Hardware buffers on the receiving devices are small and tend to run full quickly when fed at a constant rate. Therefore, VDR tries to offload the receiving device by reading the data as fast as the device allows.

I currently do not see a chance to fix this issue with the current API. Several functions would have to be changed to pass the information, that the receiving device may be blocked, to the places where buffer overflows are detected.

Bye.

Well, I just didn't expect the output device to request the packets as fast as possible, especially when buffer overflows occur. But you're right. When you consider that in the normal transmission theres kind of a "natural" limitation of the transfer rate, the system just doesn't need to deal with this. For the moment i work around the problem with program called "buffer", that i read about in this list (http://linvdr.org/mailinglists/vdr/2005/09/msg00204.html) It can deliver my stream in smaller packets, and wait a defined time until it delivers the next one. Still doesn't work perfekt, but but i can work with that.

Just another thought about the timing: MPEG-2 defines rules for a system target decoder, thats in charge for decoding and presenting the media at the right time, using the PTS-stamps in the PES packets. Is this usually done by the driver or is there a VDR instance that deals with this.

so, thank you for your answers so far.

Regards, Thomas

Hi,

Thomas Lagemann wrote:

Just another thought about the timing: MPEG-2 defines rules for a system target decoder, thats in charge for decoding and presenting the media at the right time, using the PTS-stamps in the PES packets. Is this usually done by the driver or is there a VDR instance that deals with this.

It's done in the driver / xine.

But it shouldn't be to complicated to extract the PTS value from a TS packet. The PTS value is very near to the beginning of a PES packet and a bit in the TS packet tells you that a new PES packet starts in this TS packet.

When you extract PTS for each PID and calculate the difference to the first seen PTS for each PID, then you evaluate, how much time should have passed since the beginning of the TS file. If you put this information in relation to the time passed in reality since opening the TS file, you can throttle the TS stream so that it doesn't overflow the buffers any more.

BTW: keep in mind, that video PTS jump back and forth as the images are broadcast in decoding order while the PTS time stamps describe presentation order.

Bye.

Zitat von Thomas Lagemann thomas.lagemann@stud.tu-ilmenau.de:

Reinhard Nissl wrote:

...

I currently do not see a chance to fix this issue with the current API. Several functions would have to be changed to pass the information, that the receiving device may be blocked, to the places where buffer overflows are detected.

For the moment i work around the problem with program called "buffer", that i read about in this list (http://linvdr.org/mailinglists/vdr/2005/09/msg00204.html) It can deliver my stream in smaller packets, and wait a defined time until it delivers the next one. Still doesn't work perfekt, but but i can work with that.

Found out that it's much easyer to do the waiting thing in my device. No need for an external program this way. But since the bitrate of the stream varies there's still buffer over- and underflows. Is there a way to get the buffer status of a device? This way i could just stop to deliver the ts packets, when the buffer is full and the other way round.

I alredy looked in cDevice but all i found was the ::Flush method. But i'm not shure what it does. Documentation states this: "Returns true if the device's output buffers are empty, i.e. any data which was bufferd so far has been processed."

I played araund with this a little, but it doesn't seem to depend on the buffer status...

Reagards, Thomas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.