Re: [vdr] Feature request: sort recording like extrecmenu plugin does

[Carel Willemse]

Hello Klaus,

Understood.  I’ll give it a try.

Carel

> Op 9 nov. 2017 om 11:37 heeft Klaus Schmidinger  
> het volgende geschreven:
> 
>> On 08.11.2017 12:31, ca...@nekanali.nl wrote:
>> Would it be possible to add a new sort mode for the recordings in the new
>> stable vdr release?
>> On top directories sorted on date from date high to -low
>> Below that the recordings from date high to low.
>> Later option is now only available on low to high date sort
> 
> Can you suggest a patch for that?
> 
> Klaus
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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

Re: [vdr] Feature request: sort recording like extrecmenu plugin does

[Klaus Schmidinger]

On 08.11.2017 12:31, ca...@nekanali.nl wrote:


Would it be possible to add a new sort mode for the recordings in the new
stable vdr release?

On top directories sorted on date from date high to -low
Below that the recordings from date high to low.
Later option is now only available on low to high date sort


Can you suggest a patch for that?

Klaus

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

Re: [vdr] Feature request: ERROR: video data stream broken

[Marco Göbenich]

Hi!

Thanks, seems that this information is only in debug mode visible. So no 
chance to find this information without restarting vdr.


Regards

Marco

Am 10.03.2014 11:28, schrieb Klaus Schmidinger:

On 09.03.2014 18:50, Marco Göbenich wrote:

Hi!

Would it be possible to be more precise in this error message, maybe 
which channel, transponder or  adapter is causing this.
There were some transponder changes on Astra, and now I have a lot 
"Error: video data stream broken" messages. I got a lot of parallel 
recording here.


In the log line

  Mar  8 20:45:30 vdr2 vdr: [7017] ERROR: video data stream broken

locate the number between the [...] (here [7017]) and search backwards 
for

a line that contains "tid=7017":

  Mar  8 18:11:18 vdr2 vdr: [7017] recording thread started (pid=2803, 
tid=7017, prio=high)


Right before that line you should see the information about the timer
and device used for this recording.

Klaus

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



--
Professional IT
E-Commerce, Programmierung, Datenmigration, IT-Service

Needful Marco Göbenich e.K.
Auf der Haide 31a
56203 Höhr-Grenzhausen

Fon +49 (0) 2624 / 95 29 300
Fax +49 (0) 2624 / 95 29 303

m...@needful.de

http://www.needful.de

HRA: 21295 AG Montabaur
EG-Identn.: DE 280643122


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

Re: [vdr] Feature request: ERROR: video data stream broken

[Klaus Schmidinger]

On 09.03.2014 18:50, Marco Göbenich wrote:

Hi!

Would it be possible to be more precise in this error message, maybe which 
channel, transponder or  adapter is causing this.
There were some transponder changes on Astra, and now I have a lot "Error: video 
data stream broken" messages. I got a lot of parallel recording here.


In the log line

  Mar  8 20:45:30 vdr2 vdr: [7017] ERROR: video data stream broken

locate the number between the [...] (here [7017]) and search backwards for
a line that contains "tid=7017":

  Mar  8 18:11:18 vdr2 vdr: [7017] recording thread started (pid=2803, 
tid=7017, prio=high)

Right before that line you should see the information about the timer
and device used for this recording.

Klaus

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

Re: [vdr] Feature request for VDR => multi editing

[Karim]

OK ! I understood, sorry for the mismatch...
Karim

...

BTW: you should have started an all new thread for this, not "reply"
to "VDR needs some way to detect new tuners on runtime..." and simply change
the subject. Now these two threads are intertwinded... :-(
Klaus






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

Re: [vdr] Feature request for VDR => multi editing

[Manuel Reimer]

On 08/20/2013 09:49 AM, Klaus Schmidinger wrote:

BTW: you should have started an all new thread for this, not "reply"
to "VDR needs some way to detect new tuners on runtime..." and simply
change
the subject. Now these two threads are intertwinded... :-(


X-Mailer: Microsoft Office Outlook 12.0

That says it all.

AFAIK threaded view is impossible with this MUA.

Greetings,

Manuel

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

Re: [vdr] Feature request for VDR => multi editing

[Klaus Schmidinger]

On 19.08.2013 23:52, Karim wrote:

Hi Klaus,

I record many movies, shows and series with VDR => then I make a lot of
editing.
Unfortunately, VDR allows only one editing at a time.

Is it possible to improve this feature ? I mean VDR could store all demands
in a queue, and launch them one by one, until the last editing.

This should improve greatly the usability of VDR !


This is on my list.

BTW: you should have started an all new thread for this, not "reply"
to "VDR needs some way to detect new tuners on runtime..." and simply change
the subject. Now these two threads are intertwinded... :-(

Klaus

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

Re: [vdr] Feature request for VDR => multi editing

[Petri Hintukainen]

On ma, 2013-08-19 at 23:52 +0200, Karim wrote:
> Hi Klaus,
> 
> I record many movies, shows and series with VDR => then I make a lot of
> editing. 
> Unfortunately, VDR allows only one editing at a time.
> 
> Is it possible to improve this feature ? I mean VDR could store all demands 
> in a queue, and launch them one by one, until the last editing. 

I wrote such a patch ~10 years ago. Last version is for vdr 1.6.0, I
have no idea if it applies to latest versions:
http://phivdr.dyndns.org/vdr/vdr-1.6.0-CutterQueue_and_CutterAutoDelete.patch

I think it was later added to some other patch set, maybe google can
find more recent version.

> This should improve greatly the usability of VDR !
> 
> Thank you !
> 
> Regards.
> Karim
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



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

Re: [vdr] [feature request] recording length computation and storage

[Steffen Barszus]

On Sun, 21 Aug 2011 15:45:18 +0200
Klaus Schmidinger  wrote:
> On 19.08.2011 23:56, Steffen Barszus wrote:
> > It's slow since it needs to iterate through all recordings
> > and check file size of the index file (thats what i understand from
> > Klaus comment), so divide that by number of frames of the recording
> > and thats it. the directory scanner is anyway doing the same
> > (iterating the video directory and pick up necessary information).
> > So it wouldn't add anything substantially.
> 
> Would the attached patch work for you?
> Line numbers may be off a little.

Tested and looks good to me. Shows the correct result, where possible,
no delay in getting the result and doesnt crash on strange recordings. 

Perfect :) 

Would love to see this in next developer version :)

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

Re: [vdr] [feature request] recording length computation and storage

[Klaus Schmidinger]

On 19.08.2011 23:56, Steffen Barszus wrote:

On Fri, 19 Aug 2011 22:18:03 +0200
Udo Richter  wrote:


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.


It's slow since it needs to iterate through all recordings
and check file size of the index file (thats what i understand from
Klaus comment), so divide that by number of frames of the recording and
thats it. the directory scanner is anyway doing the same (iterating
the video directory and pick up necessary information). So it wouldn't
add anything substantially.


Would the attached patch work for you?
Line numbers may be off a little.

Klaus
--- recording.h	2011/08/21 11:34:03	2.24
+++ recording.h	2011/08/21 13:10:39
@@ -89,6 +89,7 @@
   mutable char *fileName;
   mutable char *name;
   mutable int fileSizeMB;
+  mutable int numFrames;
   int channel;
   int instanceId;
   bool isPesRecording;
@@ -123,6 +124,11 @@
   int HierarchyLevels(void) const;
   void ResetResume(void) const;
   double FramesPerSecond(void) const { return framesPerSecond; }
+  int NumFrames(void) const;
+   ///< Returns the number of frames in this recording.
+   ///< If the number of frames is unknown, -1 will be returned.
+  int LengthInSeconds(void) const;
+   ///< Returns the length (in seconds) of this recording, or -1 in case of error.
   bool IsNew(void) const { return GetResume() <= 0; }
   bool IsEdited(void) const;
   bool IsPesRecording(void) const { return isPesRecording; }
--- recording.c	2011/08/21 11:19:55	2.35
+++ recording.c	2011/08/21 13:43:03
@@ -60,6 +60,7 @@
 #define DISKCHECKDELTA100 // seconds between checks for free disk space
 #define REMOVELATENCY  10 // seconds to wait until next check after removing a file
 #define MARKSUPDATEDELTA   10 // seconds between checks for updating editing marks
+#define MININDEXAGE  3600 // seconds before an index file is considered no longer to be written
 
 #define MAX_SUBTITLE_LENGTH  40
 
@@ -617,6 +618,7 @@
   instanceId = InstanceId;
   isPesRecording = false;
   framesPerSecond = DEFAULTFRAMESPERSECOND;
+  numFrames = -1;
   deleted = 0;
   // set up the actual name:
   const char *Title = Event ? Event->Title() : NULL;
@@ -676,6 +678,7 @@
   lifetime = MAXLIFETIME;
   isPesRecording = false;
   framesPerSecond = DEFAULTFRAMESPERSECOND;
+  numFrames = -1;
   deleted = 0;
   titleBuffer = NULL;
   sortBuffer = NULL;
@@ -1031,6 +1034,25 @@
   resume = RESUME_NOT_INITIALIZED;
 }
 
+int cRecording::NumFrames(void) const
+{
+  if (numFrames < 0) {
+ int nf = cIndexFile::GetLength(FileName(), IsPesRecording());
+ if (time(NULL) - LastModifiedTime(FileName()) < MININDEXAGE)
+return nf; // check again later for ongoing recordings
+ numFrames = nf;
+ }
+  return numFrames;
+}
+
+int cRecording::LengthInSeconds(void) const
+{
+  int nf = NumFrames();
+  if (nf >= 0)
+ return int((nf / FramesPerSecond() + 30) / 60) * 60;
+  return -1;
+}
+
 // --- cRecordings ---
 
 cRecordings Recordings;
@@ -1102,6 +1124,7 @@
  if (endswith(buffer, deleted ? DELEXT : RECEXT)) {
 cRecording *r = new cRecording(buffer);
 if (r->Name()) {
+   r->NumFrames(); // initializes the numFrames member
Lock();
Add(r);
ChangeState();
@@ -1514,9 +1537,6 @@
 // The maximum time to wait before giving up while catching up on an index file:
 #define MAXINDEXCATCHUP   8 // seconds
 
-// The minimum age of an index file for considering it no longer to be written:
-#define MININDEXAGE3600 // seconds
-
 struct tIndexPes {
   uint32_t offset;
   uchar type;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [feature request] recording length computation and storage

[Steffen Barszus]

On Fri, 19 Aug 2011 22:18:03 +0200
Udo Richter  wrote:

> 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.

It's slow since it needs to iterate through all recordings 
and check file size of the index file (thats what i understand from
Klaus comment), so divide that by number of frames of the recording and
thats it. the directory scanner is anyway doing the same (iterating
the video directory and pick up necessary information). So it wouldn't
add anything substantially. 

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

Re: [vdr] [feature request] recording length computation and storage

[Udo Richter]

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] [feature request] recording length computation and storage

[Steffen Barszus]

On Fri, 19 Aug 2011 14:48:46 +0200
Klaus Schmidinger  wrote:

> On 19.08.2011 14:39, Steffen Barszus wrote:
> > On Fri, 19 Aug 2011 12:21:24 +0200
> > Klaus Schmidinger  wrote:
> >
> >> On 08/19/11 11:46, Steffen Barszus wrote:
> >>> Hi !
> >>>
> >>> After having seen that there are several plug-ins computing the
> >>> recording length on their own and that being a very expensive task
> >>> (in respect of io and cpu) and also the same implementation needs
> >>> to be copied over and over again, i would like to request, that
> >>> vdr is storing the length of a recording and make it accessible
> >>> to the plug-ins. I would imagine, that some logic to store it in
> >>> the info file after/while generating/writing the index would be a
> >>> good way.
> >>>
> >>
> >> How about cIndexFile::GetLength()?
> >> This was newly added in version 1.7.20.
> >
> > Not yet - its returning the number of frames - to have one
> > calculation, length in seconds would be required (Ok, its available
> > as well).
> >
> > Also it reads the index directly (if i'm not mistaken, i can barely
> > read C), which would then be read x-times , where x is the number of
> > plugins using it ( + vdr ? I'm not sure of it ).
> >
> > I would think that in recording.h as public member of class
> > cRecordingInfo would make sense. In my understanding the recordings
> > information are held in memory after reading it with
> > ScanVideoDir, this should be part of that information in
> > memory (not reading file from disk for this separately).
> 
> I don't want to make this part of the 'info' file.
> Besides, it's only the directory entry that gets read, not
> the file itself.

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. 




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

Re: [vdr] [feature request] recording length computation and storage

[Klaus Schmidinger]

On 19.08.2011 14:39, Steffen Barszus wrote:

On Fri, 19 Aug 2011 12:21:24 +0200
Klaus Schmidinger  wrote:


On 08/19/11 11:46, Steffen Barszus wrote:

Hi !

After having seen that there are several plug-ins computing the
recording length on their own and that being a very expensive task
(in respect of io and cpu) and also the same implementation needs
to be copied over and over again, i would like to request, that vdr
is storing the length of a recording and make it accessible to the
plug-ins. I would imagine, that some logic to store it in the info
file after/while generating/writing the index would be a good way.



How about cIndexFile::GetLength()?
This was newly added in version 1.7.20.


Not yet - its returning the number of frames - to have one calculation,
length in seconds would be required (Ok, its available as well).

Also it reads the index directly (if i'm not mistaken, i can barely
read C), which would then be read x-times , where x is the number of
plugins using it ( + vdr ? I'm not sure of it ).

I would think that in recording.h as public member of class
cRecordingInfo would make sense. In my understanding the recordings
information are held in memory after reading it with
ScanVideoDir, this should be part of that information in
memory (not reading file from disk for this separately).


I don't want to make this part of the 'info' file.
Besides, it's only the directory entry that gets read, not
the file itself.

Klaus

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

Re: [vdr] [feature request] recording length computation and storage

[Steffen Barszus]

On Fri, 19 Aug 2011 12:21:24 +0200
Klaus Schmidinger  wrote:

> On 08/19/11 11:46, Steffen Barszus wrote:
> > Hi !
> >
> > After having seen that there are several plug-ins computing the
> > recording length on their own and that being a very expensive task
> > (in respect of io and cpu) and also the same implementation needs
> > to be copied over and over again, i would like to request, that vdr
> > is storing the length of a recording and make it accessible to the
> > plug-ins. I would imagine, that some logic to store it in the info
> > file after/while generating/writing the index would be a good way.
> >
> 
> How about cIndexFile::GetLength()?
> This was newly added in version 1.7.20.

Not yet - its returning the number of frames - to have one calculation,
length in seconds would be required (Ok, its available as well).

Also it reads the index directly (if i'm not mistaken, i can barely
read C), which would then be read x-times , where x is the number of
plugins using it ( + vdr ? I'm not sure of it ). 

I would think that in recording.h as public member of class
cRecordingInfo would make sense. In my understanding the recordings
information are held in memory after reading it with
ScanVideoDir, this should be part of that information in
memory (not reading file from disk for this separately).



 

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

Re: [vdr] [feature request] recording length computation and storage

[Klaus Schmidinger]

On 08/19/11 11:46, Steffen Barszus wrote:

Hi !

After having seen that there are several plug-ins computing the
recording length on their own and that being a very expensive task (in
respect of io and cpu) and also the same implementation needs to be
copied over and over again, i would like to request, that vdr is
storing the length of a recording and make it accessible to the
plug-ins. I would imagine, that some logic to store it in the info file
after/while generating/writing the index would be a good way.

Plug-ins which possibly could make use of that are:
* live
* extrecmenu
* restfulapi

I'm sure there are more of it.

Has someone allready thought of this ? Are there any plans to have that
or someone allready using a patch for this ?


How about cIndexFile::GetLength()?
This was newly added in version 1.7.20.

Klaus

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

Re: [vdr] [feature request] recording length computation and storage

[André Weidemann]

Hi Steffen,

On 19.08.2011 11:46, Steffen Barszus wrote:

Hi !

After having seen that there are several plug-ins computing the
recording length on their own and that being a very expensive task (in
respect of io and cpu) and also the same implementation needs to be
copied over and over again, i would like to request, that vdr is
storing the length of a recording and make it accessible to the
plug-ins. I would imagine, that some logic to store it in the info file
after/while generating/writing the index would be a good way.

Plug-ins which possibly could make use of that are:
* live
* extrecmenu
* restfulapi

I'm sure there are more of it.

Has someone allready thought of this ? Are there any plans to have that
or someone allready using a patch for this ?


Please correct me, if I am wrong, but I think vdr-1.7.20 has this 
feature. Take a look at recording.h:


static int GetLength(const char *FileName, bool IsPesRecording = false);
   ///< Calculates the recording length (numer of frames) without 
actually reading the index file.

   ///< Returns -1 in case of error.

Regards
 André

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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Jochen Dolze]

/On Thu Nov  4 16:14:01 CET 2010/, Rene Bartsch>ml at bartschnet.de>
 wrote:  



 Better NOT. NOAD worked relatively well, but markad messes up cutmarks.
 There are
 channels with over 50 cutmarks in one recording. I really don't want to
 remind how much
 time it has cost to remove so much wrong cutmarks from ONE 90-minute
 recording.


I never had 50 cutmarks in one recording. Always use the latest git-Version!
Feel free to report bugs onhttp://vdr-portal.de
orhttp://projects.vdr-developer.org/projects/plg-markad

Greetings

  Jochen

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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Rene Bartsch]

On Wed, 3 Nov 2010 23:05:59 +0100, Halim Sahin 
wrote:
> Hi,
> On Wed, Nov 03, 2010 at 04:56:13PM +0100, Rene Bartsch wrote:
>> The most sensible solution is to just add a UNIX_Timestamp
>> of the exact recording start to the info file.
> 
> That would need a well synchronized  systemtime to dvb-time of the
> transponder were the recording comesfrom.
> Aditionally the cuttingmarks will differ for cable/sat users due to some
> delays of the
> broadcasters etc.

Maybe the cut function of VDR can be improved to move cutmarks relatively
to the start of a recording. If you get cutlists, the offsets BETWEEN the
cutmarks are the SAME, but the offset to the START of the recording can
DIFFER. A solution would be to import cutmarks into VDR and move the first
mark to the correct position with e.g. the left/right keys. The correction
offset can then be applied to all other cut marks automatically.

> Finding a well working solutions seems dificult to me .

Not really. Sharemarks uses the PTS in the TS-stream to place exact cut
marks.
The database server is still online, but the 3 year old last version of
Sharemarks
it not compatible with VDR 1.7. Maybe someone can revive the Sharemarks
script
and adjust it to new VDR versions.

But it still would be great to have the start timestamp (and maybe the
option to
move all cutmarks with the same offset) to import non-VDR cutlists.

> Better use some of noad/markad plugin.

Better NOT. NOAD worked relatively well, but markad messes up cutmarks.
There are
channels with over 50 cutmarks in one recording. I really don't want to
remind how much
time it has cost to remove so much wrong cutmarks from ONE 90-minute
recording.

Or VDR just uses cutmarks with NTP-based timestamp and PTS in the marks
file ;-)
That way the PTS can be used and timestamps if there is no PTS or broken
PTS.

Best regards,

Renne


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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Halim Sahin]

Hi,
On Wed, Nov 03, 2010 at 04:56:13PM +0100, Rene Bartsch wrote:
> The most sensible solution is to just add a UNIX_Timestamp
> of the exact recording start to the info file.

That would need a well synchronized  systemtime to dvb-time of the
transponder were the recording comesfrom.
Aditionally the cuttingmarks will differ for cable/sat users due to some delays 
of the
broadcasters etc.
Finding a well working solutions seems dificult to me .
Better use some of noad/markad plugin.

Just My two cents.
BR.
Halim


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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Udo Richter]

Am 03.11.2010 02:24, schrieb Rene Bartsch:
>> There is no fixed start/stop margin. I have some timers with 5min before
>> / 10min after, and others with 10min before and 30min after. Depends on
>> how much delays the channel usually has.
> 
> I'm talking about the MARGINSTART in setup.conf or a manually per
> recording set one.

Exactly my point. There IS NO per recording set one. (Don't confuse this
with epgsearch search timers where there is one!) VDR adds a margin when
using an EPG event to pre-fill a timer entry. But I can still change the
starting time to be earlier/later as I want, and after storing the
timer, the exact margin is not known any more. Unless you subtract the
timer start time from the EPG time of the most probable EPG event.

If you want MARGINSTART from setup.conf, then just get it from there.


>> The time in the
>> folder name is just the timer time, not necessarily the recording start
>> time.
> There's no guarantee you survive crossing the street at your home. ;-)
> 
> If the VDR clock is reliable and the recording is not started delayed you
> get
> perfect cuts. Tried that with impressing results on a Indiana Jones
> recording.

Record something with an VPS timer on an average not-always-perfect
channel. Recording time isn't accurate.

Or some program is about to start, and you quickly go to EPG and hit
record button. Start time will instantly be some minutes in the past.

Oh, and recording time is only accurate to one minute. In the info file,
it could be accurate to a second.


Cheers,

Udo

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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Rene Bartsch]

The most sensible solution is to just add a UNIX_Timestamp
of the exact recording start to the info file.

That way offsets between EPG and real start of recording
can be calculated easily.

Renne


On Tue, 02 Nov 2010 12:20:53 +0100, Rene Bartsch  wrote:
> Hi,
> 
> I'm working on a script which downloads cutlists from cutlist.at and
> converts them to VDR format.
> As the cutmarks are relative to the start of the recording, the offset
> between start of recording
> and start of cutlist has to be calculated. I'm trying parse all
> information from the info files,
> but as the unix timestamp relates to the start of the show and not to
the
> start of the recording,
> I have to assume an fixed offset for all recordings.
> 
> So I suggest to add start margin (and maybe stop margin) to the info
files
> of recordings.
> 
> Best regards,
> 
> Renne
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Rene Bartsch]

On Tue, 02 Nov 2010 20:54:06 +0100, Udo Richter 
wrote:
> Am 02.11.2010 12:20, schrieb Rene Bartsch:
>> So I suggest to add start margin (and maybe stop margin) to the info
>> files
>> of recordings.
> 
> There is no fixed start/stop margin. I have some timers with 5min before
> / 10min after, and others with 10min before and 30min after. Depends on
> how much delays the channel usually has.

I'm talking about the MARGINSTART in setup.conf or a manually per
recording
set one.

The idea is simple:

1.) Create an OTR filename from the information in the info file
(as VDR and OTR recordings use EPG data, it's simple regex parsing)

2.) Download a cutlist for the corresponding OTR recording at Cutlist.at
(preferably rated with 5.00)

3.) Substract the 360 seconds OTR standard leader from the cut marks

4.) Add the preset VDR leader (MARGINSTART) to the cut marks

5.) Convert the cut marks to VDR marks file

6.) Be happy

Only precondition: Reliable clock in the VDR machine (e.g. radio clock or
NTP)

> Also, this would help only partially, as there's no guarantee that
> start/stop margin is actually part of the recording. The time in the
> folder name is just the timer time, not necessarily the recording start
> time. Differences may appear on VPS recordings, timers set/enabled after
> start time, and recordings that couldn't be started because of downtime
> or missing devices.

There's no guarantee you survive crossing the street at your home. ;-)

If the VDR clock is reliable and the recording is not started delayed you
get
perfect cuts. Tried that with impressing results on a Indiana Jones
recording.

Just consider: VDR stores the UNIX_TimeStamp of the EPG event which is the
same for OTR recordings. To adjust the cutmarks you only need to know the
recording start offsets of the VDR machine and OTR.

So VDR just has to store the offset between EPG event UNIX_TimeStamp and
real recording start in the info file (tried that with fixed
MARGINSTART=10
and 360 seconds for the OTR leader -> perfect match)

For delayed starts the margin in the info file 

Best regards,

Renne



P.S: The script is a dirty hack - just a proof of concept:

#!/bin/bash


# Parameters
# $1: Absolute path to recording directory
# $2: OTR name of station (e.g. 'sat1' instead of 'SAT.1')



# Cutlist rating (cutlist.at x 100, max. 500)
RATING=500


# VDR video directory
VIDEODIR=/home/vdr/video


# VDR start margin in seconds
MARGINSTART_VDR=600


# OTR start margin in seconds
MARGINSTART_OTR=360


INFO="`head -n3 $1/info`"
STATION="$(echo $INFO | sed -r -n s/'^C .* (.*) E [0-9]+ ([0-9]+) ([0-9]+)
[0-9]+[A-Z]+ [0-9]+ T (.*)$'/\\1/p)"
START="$(echo $INFO | sed -r -n s/'^C .* (.*) E [0-9]+ ([0-9]+) ([0-9]+)
[0-9]+[A-Z]+ [0-9]+ T (.*)$'/\\2/p)"
DURATION="$(echo $INFO | sed -r -n s/'^C .* (.*) E [0-9]+ ([0-9]+)
([0-9]+) [0-9]+[A-Z]+ [0-9]+ T (.*)$'/\\3/p)"
TITLE="$(echo $INFO | sed -r -n s/'^C .* (.*) E [0-9]+ ([0-9]+) ([0-9]+)
[0-9]+[A-Z]+ [0-9]+ T (.*)$'/\\4/p)"


# Stations
STATION="$2"


# Umlauts
TITLE="${TITLE//Ä/Ae}"
TITLE="${TITLE//Ö/Oe}"
TITLE="${TITLE//Ü/Ue}"
TITLE="${TITLE//ä/ae}"
TITLE="${TITLE//ö/oe}"
TITLE="${TITLE//ü/ue}"
TITLE="${TITLE//ß/ss}"


URL="http://cutlist.at/getxml.php?name=${TITLE// /_}_`date -d @$START
+%y.%m.%d_%H-%M`_${STATION}_$(($DURATION/60))_TVOON_DE.mpg.avi"
XML="`wget --quiet -O - $URL`"
if [ "$(echo -e "$XML" | sed -r -n s:'(.*)<\/rating>':\\1:p | sed
-r -n s:'([0-9]).([0-9]+)':\\1\\2:p | head -n1)" -ge $RATING ]; then {
URL="http://cutlist.at/getfile.php?id=$(echo -e "$XML" | sed -r -n
s:'(.*)<\/id>':\\1:p | head -n1)"
declare -a MARK
MARK=(`wget --quiet -O - $URL`)
for((i=0; i<${#MARK[*]}; i++)); do {
case "${MARK[$i]}" in
Start*)
MARK[$i]=`calc ${MARK[$i]#Start=} + $MARGINSTART_VDR - 
$MARGINSTART_OTR`
SEC="${MARK[$i]%.*}"
MSEC="${MARK[$i]#*.}"
MSEC="${MSEC:0:2}"
MARKS+="`printf %1d:%02d:%02d.%02d§ $(($SEC/3600)) 
$(($SEC%3600/60))
$(($SEC%3600%60)) $MSEC`"
;;
Duration*)
MARK[$i]=`calc ${MARK[$i-1]} + ${MARK[$i]#Duration=}`
SEC="${MARK[$i]%.*}"
MSEC="${MARK[$i]#*.}"
MSEC="${MSEC:0:2}"
MARKS+="`printf %1d:%02d:%02d.%02d§ $(($SEC/3600)) 
$(($SEC%3600/60))
$(($SEC%3600%60)) $MSEC`"
;;
*)
;;
esac
}; done
echo -e "${MARKS//§/\n}" > "$1\marks"
cat  "$1\marks"
}; fi


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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[VDR User]

On Tue, Nov 2, 2010 at 3:04 PM, Rolf Ahrenberg  wrote:
>> Wouldn't this also require that you sync your system time to the dvb
>> stream also?  It would be nice if someone wrote a patch or plugin to
>> cut out commercials.  From what I've _heard_ mythtv has this features
>> and it works quite well.
>
> There's already the Markad plugin, that's been developed quite actively:
> http://projects.vdr-developer.org/projects/plg-markad

I've never heard of that plugin before, will look into it.  Thanks for the url!

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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Rolf Ahrenberg]

On Tue, 2 Nov 2010, VDR User wrote:


Wouldn't this also require that you sync your system time to the dvb
stream also?  It would be nice if someone wrote a patch or plugin to
cut out commercials.  From what I've _heard_ mythtv has this features
and it works quite well.


There's already the Markad plugin, that's been developed quite actively:
http://projects.vdr-developer.org/projects/plg-markad

BR,
--
rofa

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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[VDR User]

On Tue, Nov 2, 2010 at 12:54 PM, Udo Richter  wrote:
> To get a near match, it would be necessary to store the actual recording
> start time and the EPG event start time in the info file. And maybe the
> time when the EPG event became active.

Wouldn't this also require that you sync your system time to the dvb
stream also?  It would be nice if someone wrote a patch or plugin to
cut out commercials.  From what I've _heard_ mythtv has this features
and it works quite well.

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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Udo Richter]

Am 02.11.2010 12:20, schrieb Rene Bartsch:
> So I suggest to add start margin (and maybe stop margin) to the info files
> of recordings.

There is no fixed start/stop margin. I have some timers with 5min before
/ 10min after, and others with 10min before and 30min after. Depends on
how much delays the channel usually has.

Also, this would help only partially, as there's no guarantee that
start/stop margin is actually part of the recording. The time in the
folder name is just the timer time, not necessarily the recording start
time. Differences may appear on VPS recordings, timers set/enabled after
start time, and recordings that couldn't be started because of downtime
or missing devices.

To get a near match, it would be necessary to store the actual recording
start time and the EPG event start time in the info file. And maybe the
time when the EPG event became active.


Cheers,

Udo

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

Re: [vdr] Feature-Request: MarginStart in INFO file of recording

[Matthias Wächter]

On 02.11.2010 12:20, Rene Bartsch wrote:
> So I suggest to add start margin (and maybe stop margin) to the info files
> of recordings.

Even better: Store all related EPG in the info file while recording. Set auto 
cut marks at times when EPG changes.

– Matthias

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

Re: [vdr] Feature request: program guide scroll

[István Füley]

I'd tried your patch last night, but unfortunamtely ... I haven't seen 
any changes.

My vdr 1.7.10 is patched with liemikuutio patch, and your patch applied
with some 20 line offsets, but it said, that all the hunks succeded.
I will try with a plain vdr this evening.

István

Udo Richter wrote:

Am 17.06.2010 19:29, schrieb Udo Richter:

Am 17.06.2010 17:31, schrieb martinez:
Can any kind person write this patch? 

I'll see if I can come up with something on the weekend.



As always, the more close you look on it, the more complicated it gets.
In other words, it got a little more than 12 lines... ;)

The cMenuEvent can now switch through the list of events of the parent
menu with the green and yellow buttons. Depending on the parent menu,
the buttons either show channel names or event starting times. From
timer menu (blue button), the green and yellow buttons stay empty.

To gain access to the list of events, I've added an abstract
cEventSequence class that is implemented by cMenuWhatsOn and
cMenuSchedule. That way these two and the cMenuScheduleItem can continue
to be private to menu.c.

Since now the cMenuEvent can handle different events, a convenient
shortcut had to be removed: Previously, the red and blue buttons were
handled by the parent menu, not cMenuEvent itself. cMenuEvent now does
this on its own. Also the constructor parameters CanSwitch and Buttons
were dropped and replaced by dynamic code. By this change, the event
info on blue key in timers menu gains the red and blue button for free.

cMenuEvent had its ProcessKey re-arranged, as the original version could
not handle sub-menus. (the parent menu did.)

Timer menu got a bug fix to handle sub-sub-menus without overwriting the
button bar.



The attached patch is against vdr-1.6, but also cleanly applies and
compiles on vdr-1.7.15.

A little testing help and feedback is welcome. Check that the green and
yellow buttons work in program, whats now, whats next and timer info
menu, and keep an eye on button bar text in the event menu and the
parent menu after exiting. Also, the t and T markers on events should
change, and in the timer menu the '>' for active timers, if you change
that. Try adding timers from the event menu for running and future
events. Try whether the blue key switches to the right channel. And try
whatever else you can imagine.


Cheers,

Udo




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



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

Re: [vdr] Feature request: program guide scroll

[Udo Richter]

Am 20.06.2010 00:54, schrieb Torgeir Veimo:
> On 20 June 2010 01:37, Udo Richter  wrote:
>> Am 17.06.2010 19:29, schrieb Udo Richter:
>>> Am 17.06.2010 17:31, schrieb martinez:
 Can any kind person write this patch?
>>>
>>> I'll see if I can come up with something on the weekend.
> 
> While you're at it, what about a configurable option to have the right
> and left keys change volume instead of scrolling up and down? A lot of
> remotes have the volume on those keys. It could be disable by default
> while the menu is displayed of course.

What exactly does the EPG event display have to do with the meaning of
left/right key in live TV view?

Also, the left/right key in live TV view is already in use.


Cheers,

Udo

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

Re: [vdr] Feature request: program guide scroll

[Torgeir Veimo]

On 20 June 2010 09:24, VDR User  wrote:
> On Sat, Jun 19, 2010 at 5:20 PM, Tony Houghton  wrote:
>>> There's tons of remotes with different configurations.  Some use arrow
>>> keys up/down, some use left/right, some use dedicated volume buttons.
>>> You should probably look into editing your remote.conf to properly
>>> reflect the buttons on your remote I guess.
>>
>> But can VDR work correctly if the volume keys are also left & right? Ie
>> can it use them as a volume control while playing something but use the
>> same keys for navigation in menus etc?
>
> Only takes a few seconds to give it a try!  ;)

My volume up/down keys doesn't change options in any option menu, it
only changes the volume. The idea was to have them work as left right
while the menu is active.

-- 
-Tor

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

Re: [vdr] Feature request: program guide scroll

[VDR User]

On Sat, Jun 19, 2010 at 5:20 PM, Tony Houghton  wrote:
>> There's tons of remotes with different configurations.  Some use arrow
>> keys up/down, some use left/right, some use dedicated volume buttons.
>> You should probably look into editing your remote.conf to properly
>> reflect the buttons on your remote I guess.
>
> But can VDR work correctly if the volume keys are also left & right? Ie
> can it use them as a volume control while playing something but use the
> same keys for navigation in menus etc?

Only takes a few seconds to give it a try!  ;)

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

Re: [vdr] Feature request: program guide scroll

[Tony Houghton]

On Sat, 19 Jun 2010 15:58:52 -0700
VDR User  wrote:

> On Sat, Jun 19, 2010 at 3:54 PM, Torgeir Veimo
>  wrote:
> > While you're at it, what about a configurable option to have the
> > right and left keys change volume instead of scrolling up and down?
> > A lot of remotes have the volume on those keys. It could be disable
> > by default while the menu is displayed of course.
> 
> There's tons of remotes with different configurations.  Some use arrow
> keys up/down, some use left/right, some use dedicated volume buttons.
> You should probably look into editing your remote.conf to properly
> reflect the buttons on your remote I guess.

But can VDR work correctly if the volume keys are also left & right? Ie
can it use them as a volume control while playing something but use the
same keys for navigation in menus etc?

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

Re: [vdr] Feature request: program guide scroll

[VDR User]

On Sat, Jun 19, 2010 at 3:54 PM, Torgeir Veimo  wrote:
> While you're at it, what about a configurable option to have the right
> and left keys change volume instead of scrolling up and down? A lot of
> remotes have the volume on those keys. It could be disable by default
> while the menu is displayed of course.

There's tons of remotes with different configurations.  Some use arrow
keys up/down, some use left/right, some use dedicated volume buttons.
You should probably look into editing your remote.conf to properly
reflect the buttons on your remote I guess.

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

Re: [vdr] Feature request: program guide scroll

[Torgeir Veimo]

On 20 June 2010 01:37, Udo Richter  wrote:
> Am 17.06.2010 19:29, schrieb Udo Richter:
>> Am 17.06.2010 17:31, schrieb martinez:
>>> Can any kind person write this patch?
>>
>> I'll see if I can come up with something on the weekend.

While you're at it, what about a configurable option to have the right
and left keys change volume instead of scrolling up and down? A lot of
remotes have the volume on those keys. It could be disable by default
while the menu is displayed of course.

-- 
-Tor

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

Re: [vdr] Feature request: program guide scroll

[Udo Richter]

Am 17.06.2010 19:29, schrieb Udo Richter:
> Am 17.06.2010 17:31, schrieb martinez:
>> Can any kind person write this patch? 
> 
> I'll see if I can come up with something on the weekend.


As always, the more close you look on it, the more complicated it gets.
In other words, it got a little more than 12 lines... ;)

The cMenuEvent can now switch through the list of events of the parent
menu with the green and yellow buttons. Depending on the parent menu,
the buttons either show channel names or event starting times. From
timer menu (blue button), the green and yellow buttons stay empty.

To gain access to the list of events, I've added an abstract
cEventSequence class that is implemented by cMenuWhatsOn and
cMenuSchedule. That way these two and the cMenuScheduleItem can continue
to be private to menu.c.

Since now the cMenuEvent can handle different events, a convenient
shortcut had to be removed: Previously, the red and blue buttons were
handled by the parent menu, not cMenuEvent itself. cMenuEvent now does
this on its own. Also the constructor parameters CanSwitch and Buttons
were dropped and replaced by dynamic code. By this change, the event
info on blue key in timers menu gains the red and blue button for free.

cMenuEvent had its ProcessKey re-arranged, as the original version could
not handle sub-menus. (the parent menu did.)

Timer menu got a bug fix to handle sub-sub-menus without overwriting the
button bar.



The attached patch is against vdr-1.6, but also cleanly applies and
compiles on vdr-1.7.15.

A little testing help and feedback is welcome. Check that the green and
yellow buttons work in program, whats now, whats next and timer info
menu, and keep an eye on button bar text in the event menu and the
parent menu after exiting. Also, the t and T markers on events should
change, and in the timer menu the '>' for active timers, if you change
that. Try adding timers from the event menu for running and future
events. Try whether the blue key switches to the right channel. And try
whatever else you can imagine.


Cheers,

Udo
diff -Naur vdr-1.6.0/menu.h vdr-1.6.0-MenuEventNext/menu.h
--- vdr-1.6.0/menu.h	2008-02-10 17:01:53.0 +0100
+++ vdr-1.6.0-MenuEventNext/menu.h	2010-06-19 15:33:20.0 +0200
@@ -45,12 +45,28 @@
   virtual eOSState ProcessKey(eKeys Key);
   };
 
+class cEventSequence {
+public:
+  virtual const cEvent* GetEvent(int Nr) const = 0;
+  virtual int GetEventCount() const = 0;
+};
+
 class cMenuEvent : public cOsdMenu {
 private:
   const cEvent *event;
-public:
-  cMenuEvent(const cEvent *Event, bool CanSwitch = false, bool Buttons = false);
+  const cEventSequence *eventSequence;
+  int eventNr;
+  int otherChannel;
+  char *green;
+  char *yellow;
+  void UpdateEvent();
+public:
+  cMenuEvent(const cEvent *Event);
+  cMenuEvent(const cEventSequence *Events, int EventNr);
+  virtual ~cMenuEvent();
   virtual void Display(void);
+  eOSState Record(void);
+  eOSState Switch(void);
   virtual eOSState ProcessKey(eKeys Key);
   };
 
diff -Naur vdr-1.6.0/menu.c vdr-1.6.0-MenuEventNext/menu.c
--- vdr-1.6.0/menu.c	2008-03-16 12:15:28.0 +0100
+++ vdr-1.6.0-MenuEventNext/menu.c	2010-06-19 16:38:35.0 +0200
@@ -974,27 +974,99 @@
  Add(new cMenuTimerItem(Timers.Get(TimerNumber)), true);
  Display();
  }
-  if (Key != kNone)
+  if (Key != kNone && !HasSubMenu())
  SetHelpKeys();
   return state;
 }
 
 // --- cMenuEvent 
 
-cMenuEvent::cMenuEvent(const cEvent *Event, bool CanSwitch, bool Buttons)
+cMenuEvent::cMenuEvent(const cEvent *Event)
 :cOsdMenu(tr("Event"))
 {
   event = Event;
+  eventNr = 0;
+  eventSequence = NULL;
+  green = NULL;
+  yellow = NULL;
+  UpdateEvent();
+}
+
+cMenuEvent::cMenuEvent(const cEventSequence *Events, int EventNr)
+:cOsdMenu(tr("Event"))
+{
+  eventSequence = Events;
+  eventNr = EventNr;
+  green = NULL;
+  yellow = NULL;
+  UpdateEvent();
+}
+
+cMenuEvent::~cMenuEvent() {
+  if (green)
+ free(green);
+  if (yellow)
+ free(yellow);
+}
+
+void cMenuEvent::UpdateEvent()
+{
+  const cEvent *eventPrev = NULL;
+  const cEvent *eventNext = NULL;
+  int TimerMatch = tmNone;
+  otherChannel = 0;
+
+  if (eventSequence) {
+ event = eventSequence->GetEvent(eventNr);
+ eventPrev = eventSequence->GetEvent(eventNr-1);
+ eventNext = eventSequence->GetEvent(eventNr+1);
+ }
+
   if (event) {
  cChannel *channel = Channels.GetByChannelID(event->ChannelID(), true);
  if (channel) {
 SetTitle(channel->Name());
-int TimerMatch = tmNone;
-Timers.GetMatch(event, &TimerMatch);
-if (Buttons)
-   SetHelp(TimerMatch == tmFull ? tr("Button$Timer") : tr("Button$Record"), NULL, NULL, CanSwitch ? tr("Button$Switch") : NULL);
+if (channel->Number() != cDevice::CurrentChannel())
+   otherChannel = channel->Number();
 }
+ Timers.GetMatch(event, &TimerMatch);
  }
+
+  if (green) {
+ 

Re: [vdr] Feature request: program guide scroll

[Udo Richter]

Am 17.06.2010 17:31, schrieb martinez:
>> Date: Sun, 13 Jun 2010 13:03:49 +0200
>> From: Klaus Schmidinger 
>> Subject: Re: [vdr] Feature request: program guide scroll
>>
>> Well, it has *no* priority to *me* ;-)
>> So if you want this, you can suggest a patch.
> 
> I would love to see this implemented and I would gladly write the patch
> if I had the programming skills.
> 
> Can any kind person write this patch? 


I'll see if I can come up with something on the weekend.


@Klaus: For this the cMenuEvent needs to know about the sequence of
events instead of just one event. Would it be ok for you to pass a
pointer to the parent cOsdMenu to cMenuEvent, in order to get all the
cMenuScheduleItem menu items (and their event) from it? This would
probably be in an alternate constructor. Otherwise a second list of all
matching events has to be created, to pass it on.


Cheers,

Udo

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

Re: [vdr] Feature request: program guide scroll

[Klaus Schmidinger]

On 06/07/10 11:55, István Füley wrote:
> Klaus Schmidinger wrote:
>>
>> "Left" and "Right" are used to page up/down within long list, and that's
>> not going to change. However, we could use the Green and Yellow buttons
>> (and additionally the kPrev and kNext keys) for this.
>>
>> Klaus
>>
> 
> Klaus, is this an abandoned feature, or it just has a lower priority?

Well, it has *no* priority to *me* ;-)
So if you want this, you can suggest a patch.

Klaus

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

Re: [vdr] Feature request: program guide scroll

[István Füley]

Klaus Schmidinger wrote:


"Left" and "Right" are used to page up/down within long list, and that's
not going to change. However, we could use the Green and Yellow buttons
(and additionally the kPrev and kNext keys) for this.

Klaus



Klaus, is this an abandoned feature, or it just has a lower priority?

thanks,

Füley István


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

Re: [vdr] Feature request: program guide scroll

[Klaus Schmidinger]

On 14.03.2010 10:11, Halim Sahin wrote:
> Hi,
> Is there really a need to add two more keys for the same funktion?
> In my opinion scrolling with the arrow keys is enough.

The Left/Right arrow keys scroll through the description (if it
can't be displayed in one piece). What the OP was referring to is
"scrolling" through the events of the current channal, which is a
totally different thing.

Klaus

> On So, Mär 14, 2010 at 09:02:10 +0100, marti...@embl.de wrote:
>> Hi Klaus,
>>
>> I think your proposal would be very good and increase the usuability of
>> the interface while keeping the behaviour
>> consistent.
>>
>> Can we look forward to this in 1.7.14? :)
>>
>> cheers,
>> Art
>>
>> Date: Fri, 12 Mar 2010 16:28:28 +0100
>> From: Klaus Schmidinger 
>> Subject: Re: [vdr] Feature request: program guide scroll
>> To: vdr@linuxtv.org
>> Message-ID: <4b9a5d9c.1060...@tvdr.de>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> On 12.03.2010 08:33, Istv?n F?ley wrote:
>>
>> Hello list, At the moment if I press the Guide button (or select a
>> specific program from EPG list) i can see the detailed description of the
>> event. Now pressing up/down or left/right scrolls the "Long Description",
>> if this doesn't fit in the OSD window. I wonder if it's possible to
>> implement a different behaviour for the left/right keys: to "scroll"
>> between programs. Pressing right should bring up the next event, pressing
>> left should bring up the previous event. To scroll in the OSD window Up and
>> Down are fine. 
>>
>>
>> "Left" and "Right" are used to page up/down within long list, and that's
>> not going to change. However, we could use the Green and Yellow buttons
>> (and additionally the kPrev and kNext keys) for this.
>>
>> Klaus

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

Re: [vdr] Feature request: program guide scroll

[Halim Sahin]

Hi,
Is there really a need to add two more keys for the same funktion?
In my opinion scrolling with the arrow keys is enough.

Halim


On So, Mär 14, 2010 at 09:02:10 +0100, marti...@embl.de wrote:
> Hi Klaus,
> 
> I think your proposal would be very good and increase the usuability of
> the interface while keeping the behaviour
> consistent.
> 
> Can we look forward to this in 1.7.14? :)
> 
> cheers,
> Art
> 
> Date: Fri, 12 Mar 2010 16:28:28 +0100
> From: Klaus Schmidinger 
> Subject: Re: [vdr] Feature request: program guide scroll
> To: vdr@linuxtv.org
> Message-ID: <4b9a5d9c.1060...@tvdr.de>
> Content-Type: text/plain; charset=iso-8859-1
> 
> On 12.03.2010 08:33, Istv?n F?ley wrote:
> 
> Hello list, At the moment if I press the Guide button (or select a
> specific program from EPG list) i can see the detailed description of the
> event. Now pressing up/down or left/right scrolls the "Long Description",
> if this doesn't fit in the OSD window. I wonder if it's possible to
> implement a different behaviour for the left/right keys: to "scroll"
> between programs. Pressing right should bring up the next event, pressing
> left should bring up the previous event. To scroll in the OSD window Up and
> Down are fine. 
> 
> 
> "Left" and "Right" are used to page up/down within long list, and that's
> not going to change. However, we could use the Green and Yellow buttons
> (and additionally the kPrev and kNext keys) for this.
> 
> Klaus
> 
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Halim Sahin
E-Mail: 
halim.sahin (at) t-online.de

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

Re: [vdr] Feature request: program guide scroll

[martinez]

Hi Klaus,

I think your proposal would be very good and increase the usuability of
the interface while keeping the behaviour
consistent.

Can we look forward to this in 1.7.14? :)

cheers,
Art

Date: Fri, 12 Mar 2010 16:28:28 +0100
From: Klaus Schmidinger 
Subject: Re: [vdr] Feature request: program guide scroll
To: vdr@linuxtv.org
Message-ID: <4b9a5d9c.1060...@tvdr.de>
Content-Type: text/plain; charset=iso-8859-1

On 12.03.2010 08:33, Istv?n F?ley wrote:

Hello list, At the moment if I press the Guide button (or select a
specific program from EPG list) i can see the detailed description of the
event. Now pressing up/down or left/right scrolls the "Long Description",
if this doesn't fit in the OSD window. I wonder if it's possible to
implement a different behaviour for the left/right keys: to "scroll"
between programs. Pressing right should bring up the next event, pressing
left should bring up the previous event. To scroll in the OSD window Up and
Down are fine. 


"Left" and "Right" are used to page up/down within long list, and that's
not going to change. However, we could use the Green and Yellow buttons
(and additionally the kPrev and kNext keys) for this.

Klaus



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

Re: [vdr] Feature request: program guide scroll

[Füley István]

"Left" and "Right" are used to page up/down within long list, and that's
not going to change. However, we could use the Green and Yellow buttons
(and additionally the kPrev and kNext keys) for this.

Klaus


Green and Yellow would be a perfect solution.

István
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: [vdr] Feature request: program guide scroll

[Udo Richter]

Am 12.03.2010 16:28, schrieb Klaus Schmidinger:
> On 12.03.2010 08:33, István Füley wrote:
>> I wonder if it's possible to implement a different behaviour for the
>> left/right keys: to "scroll" between programs. Pressing right should
>> bring up the next event, pressing left should bring up the previous
>> event. To scroll in the OSD window Up and Down are fine.
> 
> "Left" and "Right" are used to page up/down within long list, and that's
> not going to change. However, we could use the Green and Yellow buttons
> (and additionally the kPrev and kNext keys) for this.

epgsearch also uses the Green/Yellow keys for this, its generally a good
idea to keep the key assignment the same.
epgsearch also displays the time of the previous/next event as button
text instead of just simply showing << and >>.


Cheers,

Udo

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

Re: [vdr] Feature request: program guide scroll

[Klaus Schmidinger]

On 12.03.2010 08:33, István Füley wrote:
> Hello list,
> 
> At the moment if I press the Guide button (or select a specific program
> from EPG list) i can see the detailed description of the event. Now
> pressing up/down or left/right scrolls the "Long Description", if this
> doesn't fit in the OSD window.
> I wonder if it's possible to implement a different behaviour for the
> left/right keys: to "scroll" between programs. Pressing right should
> bring up the next event, pressing left should bring up the previous
> event. To scroll in the OSD window Up and Down are fine.

"Left" and "Right" are used to page up/down within long list, and that's
not going to change. However, we could use the Green and Yellow buttons
(and additionally the kPrev and kNext keys) for this.

Klaus

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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[André Weidemann]

Hi,

On 06.02.2010 16:05, Klaus Schmidinger wrote:


On 06.02.2010 13:55, Halim Sahin wrote:

I'd suggest to add a (plugin or settingsmenü) for vdr which alows easy
configuration of the diseqc stuff without touching diseqc.conf.
Doing this by implementing a plugin is ok for me but it should be
shipped with vdr because I think it's a core feature of a video disk recorder!


I suggest somebody writes a plugin that does this.


In September last year I started a little patch for VDR 1.6.0 with the 
intention to add OneCable support to VDR. Due to lack of time I did not 
continue the project.
If someone is interested in the code, they can take a look at it here: 
http://ilpss8.dyndns.org/hg/vdr-1.6.0-diseqc/.
I am not a skilled programmer, so I'm sure this code has some flaws. The 
setup option for OneCable is there, but there is no code behind it, yet. 
The other DiSecQ setup options should work.


 André

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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Klaus Schmidinger]

On 07.02.2010 22:27, Halim Sahin wrote:
> Hi Klaus,
> On So, Feb 07, 2010 at 09:53:14 +0100, Klaus Schmidinger wrote:
>> I guess now you know why I never even touched that "motor" topic ;-)
> 
> Sorry Klaus for touching this topic :-(.
> My intension was to have an easy way for configuring (simple) diseqc
> setups directly in vdr.

I'm sure somebody can write a plugin that offers such a configuration
dialog and writes out a diseqc.conf.

The capability to add device numbers to diseqc.conf will be in version 1.7.13.

Klaus

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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Halim Sahin]

Hi Klaus,
On So, Feb 07, 2010 at 09:53:14 +0100, Klaus Schmidinger wrote:
> I guess now you know why I never even touched that "motor" topic ;-)

Sorry Klaus for touching this topic :-(.
My intension was to have an easy way for configuring (simple) diseqc
setups directly in vdr.
Br.
Halim


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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Klaus Schmidinger]

On 07.02.2010 19:26, Timothy D. Lenz wrote:
>  On the card side, Say you have a standard s1 and a s2. The s2 can do
> both s1 and s2, but the standard only card can only do s1. There is also
> turbo mode in NA and cards that do turbo can also do standard but they
> can't do s2. We have all 3 types in use though most of the turbo mode
> requires a propriatory receiver.
> 
> There are also problems on the dish side. Two dishes, One fixed, one on
> a rotor. If each goes to a separate card, clearly, the fixed dish can
> only see what is on one sat while the rotor can see that sat plus many
> others. If the lnb on the rotor is of the dual mode type,
> circular/linear, or covers a greater range as some do, then even while
> pointing to the same sat as the fixed, it will cover stuff the fixed
> can't. There could also be ways using dual output lnbs, where the fixed
> and rotor have signals going to two cards. only one card can move the
> dish, but ether card can see ether dish. When recording 2 channels at
> the same time, vdr needs a way to know if both are on the same sat, then
> it can use the rotor for both. For recording on different sats, it
> needs to plan ahead by putting the recording that is on a sat not
> viewable by the fixed dish, on the card that can move the dish so that a
> second recordind on the sat viewable by the fixed dish goes to the other
> card. Sounds confusing, but with multi-dish setups, that happens.

I guess now you know why I never even touched that "motor" topic ;-)

I just wanted to add a simple way by which people who don't have
a setup where every DVB-S card can receive every sat position (by means
of (cascaded) multiswitches) can fine tune their diseqc.conf. There was
absolutely no intention to even think about this whole motor complexity.
That's way too complicated for my taste.

Klaus

> On 2/6/2010 5:05 PM, Klaus Schmidinger wrote:
>> On 07.02.2010 00:31, Timothy D. Lenz wrote:
>>> This would cause duplicate lines for devices that overlap, such has
>>> where there are both fixed and rotor dish. Better to include the
>>> supporting devices in the entries.
>>
>> I don't see what you mean.
>> Can you be more specific?
>>
>> Klaus
>>
>>> On 2/6/2010 4:57 AM, Klaus Schmidinger wrote:
 On 02.02.2010 07:35, Ian Bates wrote:
> On 1 Feb 2010, at 22:24, abbe normal wrote:
>> On 2/1/10, VDR User   wrote:
>>> On Mon, Feb 1, 2010 at 7:12 AM, Halim
>>> Sahin   wrote:
 Hi List and Klaus,

 It would be really nice if vdr could support diseqc setup
 directly in
 vdr.

 I don't know if this can be done by a plugin but the current
 solution is
 difficult for endusers.
 Setting a diseqc.conf needs some knowledge in diseqc and it's
 commands.
 A simple interface for creating a diseqc.conf can improove the
 usability of vdr!
>>> Personally I think adding support for multiple diseqc switches is a
>>> more important feature as I've noticed several users asking how
>>> to do
>>> this in VDR -- which it unfortunately doesn't support.  I think this
>>> is actually one of the reasons some guys fumble around trying to
>>> cascade their diseqc switches.  However, not all switches can be
>>> cascaded and so they're left stuck.  Can't cascade, and no
>>> support for
>>> multiple switches.
>>>
>>>
>> hey guys
>>
>> i agree multi cards should be able to use mutli diseqc configs... or
>> at least be able to assign them to different switches that could be
>> used... would be nice to add more dishes and lnbs to my setup...
>> would
>> like to do c and ku band dvb as well as have at least 2 to 3 fixed
>> dishes with lnbs on them now im limited to 4 max or use a very costly
>> switch...
>>
>> abby
>
> Dear all,
>
> I have a diseqc-patch I that hacked together a couple of years ago
> relating to multi-cards/multi-switches that has served my purpose
> well.  It may not be the best way, it may even be the wrong way.  I
> will drag it out of the VDR box for all to see but that will not be
> for a couple of days.
>
> MOTIVATION
>
> I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card
> attached to a 4-way diseqc switch.  Despite the switches being the
> same model and bought at the same time each one responds to a
> different set of diseqc commands to change LNB.  IIRC one seemed to
> behave as a cascade of 2-way switches, the other responded to the
> more usual commands for a 4-way switch.
>
> DESCRIPTION
>
> Enter my hack.  It allows diseqc commands to be defined on a per-card
> basis (numbered 1, 2, ...).  How you determine which number
> corresponds to which card is left as an exercise for the reader
> (hint: the margin may not be big enough).  These defines are placed
> in 'diseqc-multi.conf' and 

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Timothy D. Lenz]

 On the card side, Say you have a standard s1 and a s2. The s2 can do 
both s1 and s2, but the standard only card can only do s1. There is also 
turbo mode in NA and cards that do turbo can also do standard but they 
can't do s2. We have all 3 types in use though most of the turbo mode 
requires a propriatory receiver.


There are also problems on the dish side. Two dishes, One fixed, one on 
a rotor. If each goes to a separate card, clearly, the fixed dish can 
only see what is on one sat while the rotor can see that sat plus many 
others. If the lnb on the rotor is of the dual mode type, 
circular/linear, or covers a greater range as some do, then even while 
pointing to the same sat as the fixed, it will cover stuff the fixed 
can't. There could also be ways using dual output lnbs, where the fixed 
and rotor have signals going to two cards. only one card can move the 
dish, but ether card can see ether dish. When recording 2 channels at 
the same time, vdr needs a way to know if both are on the same sat, then 
it can use the rotor for both. For recording on different sats, it
needs to plan ahead by putting the recording that is on a sat not 
viewable by the fixed dish, on the card that can move the dish so that a 
second recordind on the sat viewable by the fixed dish goes to the other 
card. Sounds confusing, but with multi-dish setups, that happens.


On 2/6/2010 5:05 PM, Klaus Schmidinger wrote:

On 07.02.2010 00:31, Timothy D. Lenz wrote:

This would cause duplicate lines for devices that overlap, such has
where there are both fixed and rotor dish. Better to include the
supporting devices in the entries.


I don't see what you mean.
Can you be more specific?

Klaus


On 2/6/2010 4:57 AM, Klaus Schmidinger wrote:

On 02.02.2010 07:35, Ian Bates wrote:

On 1 Feb 2010, at 22:24, abbe normal wrote:

On 2/1/10, VDR User   wrote:

On Mon, Feb 1, 2010 at 7:12 AM, Halim
Sahin   wrote:

Hi List and Klaus,

It would be really nice if vdr could support diseqc setup directly in
vdr.

I don't know if this can be done by a plugin but the current
solution is
difficult for endusers.
Setting a diseqc.conf needs some knowledge in diseqc and it's
commands.
A simple interface for creating a diseqc.conf can improove the
usability of vdr!

Personally I think adding support for multiple diseqc switches is a
more important feature as I've noticed several users asking how to do
this in VDR -- which it unfortunately doesn't support.  I think this
is actually one of the reasons some guys fumble around trying to
cascade their diseqc switches.  However, not all switches can be
cascaded and so they're left stuck.  Can't cascade, and no support for
multiple switches.



hey guys

i agree multi cards should be able to use mutli diseqc configs... or
at least be able to assign them to different switches that could be
used... would be nice to add more dishes and lnbs to my setup... would
like to do c and ku band dvb as well as have at least 2 to 3 fixed
dishes with lnbs on them now im limited to 4 max or use a very costly
switch...

abby


Dear all,

I have a diseqc-patch I that hacked together a couple of years ago
relating to multi-cards/multi-switches that has served my purpose
well.  It may not be the best way, it may even be the wrong way.  I
will drag it out of the VDR box for all to see but that will not be
for a couple of days.

MOTIVATION

I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card
attached to a 4-way diseqc switch.  Despite the switches being the
same model and bought at the same time each one responds to a
different set of diseqc commands to change LNB.  IIRC one seemed to
behave as a cascade of 2-way switches, the other responded to the
more usual commands for a 4-way switch.

DESCRIPTION

Enter my hack.  It allows diseqc commands to be defined on a per-card
basis (numbered 1, 2, ...).  How you determine which number
corresponds to which card is left as an exercise for the reader
(hint: the margin may not be big enough).  These defines are placed
in 'diseqc-multi.conf' and start with the card number but are
otherwise the same format as those found in 'diseqc.conf'.

CONFIGURATION

Configuration options within VDR are:

- use only the diseqc.conf defines,
- use only the diseqc-multi.conf,
- use the disqc-multi.conf if a card definition appears otherwise use
the diseqc.conf defines.


I don't like the introduction of a separate diseqc-multi.conf file,
and also those additional setup options in VDR.

What about simply extending the existing diseqc.conf file to
accept device numbers, as in:

1 2 4:

S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T

3 5:

S13.0E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
S13.0E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
S13.0E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
S13.0E 

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Klaus Schmidinger]

On 06.02.2010 16:58, Klaus Schmidinger wrote:
> ...
> Please give the attached patch a try.

Correction: it needs to be "CardIndex() + 1" instead of DeviceNumber():

  dvbTuner = new cDvbTuner(CardIndex() + 1, fd_frontend, adapter, frontend, 
frontendType);

  if (!Setup.DiSEqC || Diseqcs.Get(CardIndex() + 1, Channel->Source(), 
Channel->Frequency(), Channel->Polarization()))

Klaus

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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Klaus Schmidinger]

On 07.02.2010 00:31, Timothy D. Lenz wrote:
> This would cause duplicate lines for devices that overlap, such has
> where there are both fixed and rotor dish. Better to include the
> supporting devices in the entries.

I don't see what you mean.
Can you be more specific?

Klaus

> On 2/6/2010 4:57 AM, Klaus Schmidinger wrote:
>> On 02.02.2010 07:35, Ian Bates wrote:
>>> On 1 Feb 2010, at 22:24, abbe normal wrote:
 On 2/1/10, VDR User  wrote:
> On Mon, Feb 1, 2010 at 7:12 AM, Halim
> Sahin  wrote:
>> Hi List and Klaus,
>>
>> It would be really nice if vdr could support diseqc setup directly in
>> vdr.
>>
>> I don't know if this can be done by a plugin but the current
>> solution is
>> difficult for endusers.
>> Setting a diseqc.conf needs some knowledge in diseqc and it's
>> commands.
>> A simple interface for creating a diseqc.conf can improove the
>> usability of vdr!
> Personally I think adding support for multiple diseqc switches is a
> more important feature as I've noticed several users asking how to do
> this in VDR -- which it unfortunately doesn't support.  I think this
> is actually one of the reasons some guys fumble around trying to
> cascade their diseqc switches.  However, not all switches can be
> cascaded and so they're left stuck.  Can't cascade, and no support for
> multiple switches.
>
>
 hey guys

 i agree multi cards should be able to use mutli diseqc configs... or
 at least be able to assign them to different switches that could be
 used... would be nice to add more dishes and lnbs to my setup... would
 like to do c and ku band dvb as well as have at least 2 to 3 fixed
 dishes with lnbs on them now im limited to 4 max or use a very costly
 switch...

 abby
>>>
>>> Dear all,
>>>
>>> I have a diseqc-patch I that hacked together a couple of years ago
>>> relating to multi-cards/multi-switches that has served my purpose
>>> well.  It may not be the best way, it may even be the wrong way.  I
>>> will drag it out of the VDR box for all to see but that will not be
>>> for a couple of days.
>>>
>>> MOTIVATION
>>>
>>> I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card
>>> attached to a 4-way diseqc switch.  Despite the switches being the
>>> same model and bought at the same time each one responds to a
>>> different set of diseqc commands to change LNB.  IIRC one seemed to
>>> behave as a cascade of 2-way switches, the other responded to the
>>> more usual commands for a 4-way switch.
>>>
>>> DESCRIPTION
>>>
>>> Enter my hack.  It allows diseqc commands to be defined on a per-card
>>> basis (numbered 1, 2, ...).  How you determine which number
>>> corresponds to which card is left as an exercise for the reader
>>> (hint: the margin may not be big enough).  These defines are placed
>>> in 'diseqc-multi.conf' and start with the card number but are
>>> otherwise the same format as those found in 'diseqc.conf'.
>>>
>>> CONFIGURATION
>>>
>>> Configuration options within VDR are:
>>>
>>> - use only the diseqc.conf defines,
>>> - use only the diseqc-multi.conf,
>>> - use the disqc-multi.conf if a card definition appears otherwise use
>>> the diseqc.conf defines.
>>
>> I don't like the introduction of a separate diseqc-multi.conf file,
>> and also those additional setup options in VDR.
>>
>> What about simply extending the existing diseqc.conf file to
>> accept device numbers, as in:
>>
>> 1 2 4:
>>
>> S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
>> S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
>> S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
>> S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T
>>
>> 3 5:
>>
>> S13.0E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
>> S13.0E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
>> S13.0E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
>> S13.0E  9 H 10600  t V W15 [E0 10 38 F7] W15 B W15 T
>>
>>
>> This could mean that devices 1, 2 and 4 can receive S19.2E,
>> while devices 3 and 5 can receive S13.0E.
>>
>> If no device numbers (followed by a ':') are given, a setup
>> where every device can receive every satellite is assumed.
>>
>> Once a line with device numbers (followed by a ':') appears,
>> these apply to all following diseqc lines, until the next
>> line with device numbers is seen.
>> If a diseqc line is parsed without a previous device line,
>> that diseqc line applies to all devices.
>>
>> Klaus

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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Timothy D. Lenz]

This would cause duplicate lines for devices that overlap, such has 
where there are both fixed and rotor dish. Better to include the 
supporting devices in the entries.



On 2/6/2010 4:57 AM, Klaus Schmidinger wrote:

On 02.02.2010 07:35, Ian Bates wrote:

On 1 Feb 2010, at 22:24, abbe normal wrote:

On 2/1/10, VDR User  wrote:

On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin  wrote:

Hi List and Klaus,

It would be really nice if vdr could support diseqc setup directly in
vdr.

I don't know if this can be done by a plugin but the current solution is
difficult for endusers.
Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
A simple interface for creating a diseqc.conf can improove the
usability of vdr!

Personally I think adding support for multiple diseqc switches is a
more important feature as I've noticed several users asking how to do
this in VDR -- which it unfortunately doesn't support.  I think this
is actually one of the reasons some guys fumble around trying to
cascade their diseqc switches.  However, not all switches can be
cascaded and so they're left stuck.  Can't cascade, and no support for
multiple switches.



hey guys

i agree multi cards should be able to use mutli diseqc configs... or
at least be able to assign them to different switches that could be
used... would be nice to add more dishes and lnbs to my setup... would
like to do c and ku band dvb as well as have at least 2 to 3 fixed
dishes with lnbs on them now im limited to 4 max or use a very costly
switch...

abby


Dear all,

I have a diseqc-patch I that hacked together a couple of years ago relating to 
multi-cards/multi-switches that has served my purpose well.  It may not be the 
best way, it may even be the wrong way.  I will drag it out of the VDR box for 
all to see but that will not be for a couple of days.

MOTIVATION

I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached to a 
4-way diseqc switch.  Despite the switches being the same model and bought at 
the same time each one responds to a different set of diseqc commands to change 
LNB.  IIRC one seemed to behave as a cascade of 2-way switches, the other 
responded to the more usual commands for a 4-way switch.

DESCRIPTION

Enter my hack.  It allows diseqc commands to be defined on a per-card basis 
(numbered 1, 2, ...).  How you determine which number corresponds to which card 
is left as an exercise for the reader (hint: the margin may not be big enough). 
 These defines are placed in 'diseqc-multi.conf' and start with the card number 
but are otherwise the same format as those found in 'diseqc.conf'.

CONFIGURATION

Configuration options within VDR are:

- use only the diseqc.conf defines,
- use only the diseqc-multi.conf,
- use the disqc-multi.conf if a card definition appears otherwise use the 
diseqc.conf defines.


I don't like the introduction of a separate diseqc-multi.conf file,
and also those additional setup options in VDR.

What about simply extending the existing diseqc.conf file to
accept device numbers, as in:

1 2 4:

S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T

3 5:

S13.0E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
S13.0E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
S13.0E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
S13.0E  9 H 10600  t V W15 [E0 10 38 F7] W15 B W15 T


This could mean that devices 1, 2 and 4 can receive S19.2E,
while devices 3 and 5 can receive S13.0E.

If no device numbers (followed by a ':') are given, a setup
where every device can receive every satellite is assumed.

Once a line with device numbers (followed by a ':') appears,
these apply to all following diseqc lines, until the next
line with device numbers is seen.
If a diseqc line is parsed without a previous device line,
that diseqc line applies to all devices.

Klaus









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



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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Klaus Schmidinger]

On 06.02.2010 13:38, Klaus Schmidinger wrote:
> On 06.02.2010 13:26, Ian Bates wrote:
>> On 6 Feb 2010, at 11:57, Klaus Schmidinger wrote:
>>
>>> On 02.02.2010 07:35, Ian Bates wrote:
 On 1 Feb 2010, at 22:24, abbe normal wrote:
> On 2/1/10, VDR User  wrote:
>> On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin  
>> wrote:
>>> Hi List and Klaus,
>>>
>>> It would be really nice if vdr could support diseqc setup directly in
>>> vdr.
>>>
>>> I don't know if this can be done by a plugin but the current solution is
>>> difficult for endusers.
>>> Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
>>> A simple interface for creating a diseqc.conf can improove the
>>> usability of vdr!
>> Personally I think adding support for multiple diseqc switches is a
>> more important feature as I've noticed several users asking how to do
>> this in VDR -- which it unfortunately doesn't support.  I think this
>> is actually one of the reasons some guys fumble around trying to
>> cascade their diseqc switches.  However, not all switches can be
>> cascaded and so they're left stuck.  Can't cascade, and no support for
>> multiple switches.
>>
>>
> hey guys
>
> i agree multi cards should be able to use mutli diseqc configs... or
> at least be able to assign them to different switches that could be
> used... would be nice to add more dishes and lnbs to my setup... would
> like to do c and ku band dvb as well as have at least 2 to 3 fixed
> dishes with lnbs on them now im limited to 4 max or use a very costly
> switch...
>
> abby
 Dear all,

 I have a diseqc-patch I that hacked together a couple of years ago 
 relating to multi-cards/multi-switches that has served my purpose well.  
 It may not be the best way, it may even be the wrong way.  I will drag it 
 out of the VDR box for all to see but that will not be for a couple of 
 days.

 MOTIVATION

 I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached 
 to a 4-way diseqc switch.  Despite the switches being the same model and 
 bought at the same time each one responds to a different set of diseqc 
 commands to change LNB.  IIRC one seemed to behave as a cascade of 2-way 
 switches, the other responded to the more usual commands for a 4-way 
 switch.

 DESCRIPTION

 Enter my hack.  It allows diseqc commands to be defined on a per-card 
 basis (numbered 1, 2, ...).  How you determine which number corresponds to 
 which card is left as an exercise for the reader (hint: the margin may not 
 be big enough).  These defines are placed in 'diseqc-multi.conf' and start 
 with the card number but are otherwise the same format as those found in 
 'diseqc.conf'.

 CONFIGURATION

 Configuration options within VDR are:

 - use only the diseqc.conf defines, 
 - use only the diseqc-multi.conf, 
 - use the disqc-multi.conf if a card definition appears otherwise use the 
 diseqc.conf defines.
>>> I don't like the introduction of a separate diseqc-multi.conf file,
>>> and also those additional setup options in VDR.
>>>
>>> What about simply extending the existing diseqc.conf file to
>>> accept device numbers, as in:
>>>
>>> 1 2 4:
>>>
>>> S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
>>> S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
>>> S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
>>> S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T
>>>
>>> 3 5:
>>>
>>> S13.0E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
>>> S13.0E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
>>> S13.0E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
>>> S13.0E  9 H 10600  t V W15 [E0 10 38 F7] W15 B W15 T
>>>
>>>
>>> This could mean that devices 1, 2 and 4 can receive S19.2E,
>>> while devices 3 and 5 can receive S13.0E.
>>>
>>> If no device numbers (followed by a ':') are given, a setup
>>> where every device can receive every satellite is assumed.
>>>
>>> Once a line with device numbers (followed by a ':') appears,
>>> these apply to all following diseqc lines, until the next
>>> line with device numbers is seen.
>>> If a diseqc line is parsed without a previous device line,
>>> that diseqc line applies to all devices.
>>>
>>> Klaus
>>
>> Dear Klaus, all,
>>
>> That sounds good.  Using this proposal I would configure my system with the 
>> following diseqc.conf:
>>
>> # diseqc.conf
>>
>> S28.2E a1...
>> S28.2E a2...
>> S28.2E a3...
>> S28.2E a4...
>>
>> S19.2E b1...
>> S19.2E b2...
>> S19.2E b3...
>> S19.2E b4...
>>
>> S13.0E c1...
>> S13.0E c2...
>> S13.0E c3...
>> S13.0E c4...
>>
>> 2:
>>
>> S28.2E A1...
>> S28.2E A2...
>> S28.2E A3...
>> S28.2E A4...
>>
>> S19.2E B1...
>> S19.2E B2...
>> S19.2E B3...
>> S19.2E B4...
>>
>> S13.0E B1...
>> S13.0E B2...
>> S13.0E B3...
>> S13

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Klaus Schmidinger]

On 06.02.2010 13:55, Halim Sahin wrote:
> Hi Klaus,
> Thx for your response for this request :-).
> My initial intension was a bit different than the later diskusion went
> on.
> 
> I'd suggest to add a (plugin or settingsmenü) for vdr which alows easy
> configuration of the diseqc stuff without touching diseqc.conf.
> Doing this by implementing a plugin is ok for me but it should be
> shipped with vdr because I think it's a core feature of a video disk recorder!

I suggest somebody writes a plugin that does this.

Klaus

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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Halim Sahin]

Hi Klaus,
Thx for your response for this request :-).
My initial intension was a bit different than the later diskusion went
on.

I'd suggest to add a (plugin or settingsmenü) for vdr which alows easy
configuration of the diseqc stuff without touching diseqc.conf.
Doing this by implementing a plugin is ok for me but it should be
shipped with vdr because I think it's a core feature of a video disk recorder!
BR.
Halim


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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Klaus Schmidinger]

On 06.02.2010 13:26, Ian Bates wrote:
> On 6 Feb 2010, at 11:57, Klaus Schmidinger wrote:
> 
>> On 02.02.2010 07:35, Ian Bates wrote:
>>> On 1 Feb 2010, at 22:24, abbe normal wrote:
 On 2/1/10, VDR User  wrote:
> On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin  
> wrote:
>> Hi List and Klaus,
>>
>> It would be really nice if vdr could support diseqc setup directly in
>> vdr.
>>
>> I don't know if this can be done by a plugin but the current solution is
>> difficult for endusers.
>> Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
>> A simple interface for creating a diseqc.conf can improove the
>> usability of vdr!
> Personally I think adding support for multiple diseqc switches is a
> more important feature as I've noticed several users asking how to do
> this in VDR -- which it unfortunately doesn't support.  I think this
> is actually one of the reasons some guys fumble around trying to
> cascade their diseqc switches.  However, not all switches can be
> cascaded and so they're left stuck.  Can't cascade, and no support for
> multiple switches.
>
>
 hey guys

 i agree multi cards should be able to use mutli diseqc configs... or
 at least be able to assign them to different switches that could be
 used... would be nice to add more dishes and lnbs to my setup... would
 like to do c and ku band dvb as well as have at least 2 to 3 fixed
 dishes with lnbs on them now im limited to 4 max or use a very costly
 switch...

 abby
>>> Dear all,
>>>
>>> I have a diseqc-patch I that hacked together a couple of years ago relating 
>>> to multi-cards/multi-switches that has served my purpose well.  It may not 
>>> be the best way, it may even be the wrong way.  I will drag it out of the 
>>> VDR box for all to see but that will not be for a couple of days.
>>>
>>> MOTIVATION
>>>
>>> I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached to 
>>> a 4-way diseqc switch.  Despite the switches being the same model and 
>>> bought at the same time each one responds to a different set of diseqc 
>>> commands to change LNB.  IIRC one seemed to behave as a cascade of 2-way 
>>> switches, the other responded to the more usual commands for a 4-way switch.
>>>
>>> DESCRIPTION
>>>
>>> Enter my hack.  It allows diseqc commands to be defined on a per-card basis 
>>> (numbered 1, 2, ...).  How you determine which number corresponds to which 
>>> card is left as an exercise for the reader (hint: the margin may not be big 
>>> enough).  These defines are placed in 'diseqc-multi.conf' and start with 
>>> the card number but are otherwise the same format as those found in 
>>> 'diseqc.conf'.
>>>
>>> CONFIGURATION
>>>
>>> Configuration options within VDR are:
>>>
>>> - use only the diseqc.conf defines, 
>>> - use only the diseqc-multi.conf, 
>>> - use the disqc-multi.conf if a card definition appears otherwise use the 
>>> diseqc.conf defines.
>> I don't like the introduction of a separate diseqc-multi.conf file,
>> and also those additional setup options in VDR.
>>
>> What about simply extending the existing diseqc.conf file to
>> accept device numbers, as in:
>>
>> 1 2 4:
>>
>> S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
>> S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
>> S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
>> S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T
>>
>> 3 5:
>>
>> S13.0E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
>> S13.0E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
>> S13.0E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
>> S13.0E  9 H 10600  t V W15 [E0 10 38 F7] W15 B W15 T
>>
>>
>> This could mean that devices 1, 2 and 4 can receive S19.2E,
>> while devices 3 and 5 can receive S13.0E.
>>
>> If no device numbers (followed by a ':') are given, a setup
>> where every device can receive every satellite is assumed.
>>
>> Once a line with device numbers (followed by a ':') appears,
>> these apply to all following diseqc lines, until the next
>> line with device numbers is seen.
>> If a diseqc line is parsed without a previous device line,
>> that diseqc line applies to all devices.
>>
>> Klaus
> 
> 
> Dear Klaus, all,
> 
> That sounds good.  Using this proposal I would configure my system with the 
> following diseqc.conf:
> 
> # diseqc.conf
> 
> S28.2E a1...
> S28.2E a2...
> S28.2E a3...
> S28.2E a4...
> 
> S19.2E b1...
> S19.2E b2...
> S19.2E b3...
> S19.2E b4...
> 
> S13.0E c1...
> S13.0E c2...
> S13.0E c3...
> S13.0E c4...
> 
> 2:
> 
> S28.2E A1...
> S28.2E A2...
> S28.2E A3...
> S28.2E A4...
> 
> S19.2E B1...
> S19.2E B2...
> S19.2E B3...
> S19.2E B4...
> 
> S13.0E B1...
> S13.0E B2...
> S13.0E B3...
> S13.0E B4...
> 
> # EOF
> 
> where [a-cA-C][1-4]... are diseqc command sequences.
> 
> If I understand correctly, with Klaus' proposal my 'normal' switch (card 1) 
> would use the [a-c][1-4]

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Ian Bates]

On 6 Feb 2010, at 11:57, Klaus Schmidinger wrote:

> On 02.02.2010 07:35, Ian Bates wrote:
>> On 1 Feb 2010, at 22:24, abbe normal wrote:
>>> On 2/1/10, VDR User  wrote:
 On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin  
 wrote:
> Hi List and Klaus,
> 
> It would be really nice if vdr could support diseqc setup directly in
> vdr.
> 
> I don't know if this can be done by a plugin but the current solution is
> difficult for endusers.
> Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
> A simple interface for creating a diseqc.conf can improove the
> usability of vdr!
 Personally I think adding support for multiple diseqc switches is a
 more important feature as I've noticed several users asking how to do
 this in VDR -- which it unfortunately doesn't support.  I think this
 is actually one of the reasons some guys fumble around trying to
 cascade their diseqc switches.  However, not all switches can be
 cascaded and so they're left stuck.  Can't cascade, and no support for
 multiple switches.
 
 
>>> hey guys
>>> 
>>> i agree multi cards should be able to use mutli diseqc configs... or
>>> at least be able to assign them to different switches that could be
>>> used... would be nice to add more dishes and lnbs to my setup... would
>>> like to do c and ku band dvb as well as have at least 2 to 3 fixed
>>> dishes with lnbs on them now im limited to 4 max or use a very costly
>>> switch...
>>> 
>>> abby
>> 
>> Dear all,
>> 
>> I have a diseqc-patch I that hacked together a couple of years ago relating 
>> to multi-cards/multi-switches that has served my purpose well.  It may not 
>> be the best way, it may even be the wrong way.  I will drag it out of the 
>> VDR box for all to see but that will not be for a couple of days.
>> 
>> MOTIVATION
>> 
>> I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached to 
>> a 4-way diseqc switch.  Despite the switches being the same model and bought 
>> at the same time each one responds to a different set of diseqc commands to 
>> change LNB.  IIRC one seemed to behave as a cascade of 2-way switches, the 
>> other responded to the more usual commands for a 4-way switch.
>> 
>> DESCRIPTION
>> 
>> Enter my hack.  It allows diseqc commands to be defined on a per-card basis 
>> (numbered 1, 2, ...).  How you determine which number corresponds to which 
>> card is left as an exercise for the reader (hint: the margin may not be big 
>> enough).  These defines are placed in 'diseqc-multi.conf' and start with the 
>> card number but are otherwise the same format as those found in 
>> 'diseqc.conf'.
>> 
>> CONFIGURATION
>> 
>> Configuration options within VDR are:
>> 
>> - use only the diseqc.conf defines, 
>> - use only the diseqc-multi.conf, 
>> - use the disqc-multi.conf if a card definition appears otherwise use the 
>> diseqc.conf defines.
> 
> I don't like the introduction of a separate diseqc-multi.conf file,
> and also those additional setup options in VDR.
> 
> What about simply extending the existing diseqc.conf file to
> accept device numbers, as in:
> 
> 1 2 4:
> 
> S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
> S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
> S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
> S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T
> 
> 3 5:
> 
> S13.0E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
> S13.0E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
> S13.0E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
> S13.0E  9 H 10600  t V W15 [E0 10 38 F7] W15 B W15 T
> 
> 
> This could mean that devices 1, 2 and 4 can receive S19.2E,
> while devices 3 and 5 can receive S13.0E.
> 
> If no device numbers (followed by a ':') are given, a setup
> where every device can receive every satellite is assumed.
> 
> Once a line with device numbers (followed by a ':') appears,
> these apply to all following diseqc lines, until the next
> line with device numbers is seen.
> If a diseqc line is parsed without a previous device line,
> that diseqc line applies to all devices.
> 
> Klaus


Dear Klaus, all,

That sounds good.  Using this proposal I would configure my system with the 
following diseqc.conf:

# diseqc.conf

S28.2E a1...
S28.2E a2...
S28.2E a3...
S28.2E a4...

S19.2E b1...
S19.2E b2...
S19.2E b3...
S19.2E b4...

S13.0E c1...
S13.0E c2...
S13.0E c3...
S13.0E c4...

2:

S28.2E A1...
S28.2E A2...
S28.2E A3...
S28.2E A4...

S19.2E B1...
S19.2E B2...
S19.2E B3...
S19.2E B4...

S13.0E B1...
S13.0E B2...
S13.0E B3...
S13.0E B4...

# EOF

where [a-cA-C][1-4]... are diseqc command sequences.

If I understand correctly, with Klaus' proposal my 'normal' switch (card 1) 
would use the [a-c][1-4]... commands, and my problem switch (attached to card 
2) would use the [A-C][1-4]... commands.  Any additional cards would also use 
the [a-c][1-4]... commands.

Unless I have understood incorrectly this

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Klaus Schmidinger]

On 02.02.2010 07:35, Ian Bates wrote:
> On 1 Feb 2010, at 22:24, abbe normal wrote:
>> On 2/1/10, VDR User  wrote:
>>> On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin  wrote:
 Hi List and Klaus,

 It would be really nice if vdr could support diseqc setup directly in
 vdr.

 I don't know if this can be done by a plugin but the current solution is
 difficult for endusers.
 Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
 A simple interface for creating a diseqc.conf can improove the
 usability of vdr!
>>> Personally I think adding support for multiple diseqc switches is a
>>> more important feature as I've noticed several users asking how to do
>>> this in VDR -- which it unfortunately doesn't support.  I think this
>>> is actually one of the reasons some guys fumble around trying to
>>> cascade their diseqc switches.  However, not all switches can be
>>> cascaded and so they're left stuck.  Can't cascade, and no support for
>>> multiple switches.
>>>
>>>
>> hey guys
>>
>> i agree multi cards should be able to use mutli diseqc configs... or
>> at least be able to assign them to different switches that could be
>> used... would be nice to add more dishes and lnbs to my setup... would
>> like to do c and ku band dvb as well as have at least 2 to 3 fixed
>> dishes with lnbs on them now im limited to 4 max or use a very costly
>> switch...
>>
>> abby
> 
> Dear all,
> 
> I have a diseqc-patch I that hacked together a couple of years ago relating 
> to multi-cards/multi-switches that has served my purpose well.  It may not be 
> the best way, it may even be the wrong way.  I will drag it out of the VDR 
> box for all to see but that will not be for a couple of days.
> 
> MOTIVATION
> 
> I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached to a 
> 4-way diseqc switch.  Despite the switches being the same model and bought at 
> the same time each one responds to a different set of diseqc commands to 
> change LNB.  IIRC one seemed to behave as a cascade of 2-way switches, the 
> other responded to the more usual commands for a 4-way switch.
> 
> DESCRIPTION
> 
> Enter my hack.  It allows diseqc commands to be defined on a per-card basis 
> (numbered 1, 2, ...).  How you determine which number corresponds to which 
> card is left as an exercise for the reader (hint: the margin may not be big 
> enough).  These defines are placed in 'diseqc-multi.conf' and start with the 
> card number but are otherwise the same format as those found in 'diseqc.conf'.
> 
> CONFIGURATION
> 
> Configuration options within VDR are:
> 
> - use only the diseqc.conf defines, 
> - use only the diseqc-multi.conf, 
> - use the disqc-multi.conf if a card definition appears otherwise use the 
> diseqc.conf defines.

I don't like the introduction of a separate diseqc-multi.conf file,
and also those additional setup options in VDR.

What about simply extending the existing diseqc.conf file to
accept device numbers, as in:

1 2 4:

S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T

3 5:

S13.0E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
S13.0E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
S13.0E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
S13.0E  9 H 10600  t V W15 [E0 10 38 F7] W15 B W15 T


This could mean that devices 1, 2 and 4 can receive S19.2E,
while devices 3 and 5 can receive S13.0E.

If no device numbers (followed by a ':') are given, a setup
where every device can receive every satellite is assumed.

Once a line with device numbers (followed by a ':') appears,
these apply to all following diseqc lines, until the next
line with device numbers is seen.
If a diseqc line is parsed without a previous device line,
that diseqc line applies to all devices.

Klaus









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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[VDR User]

On Tue, Feb 2, 2010 at 5:54 AM, Bikalexander  wrote:
> I believe that GoToX and go to position is also very important. Could it be
> that maybe all the patches that have been published here so far we do not
> have Klaus fallen?
>
> Is it perhaps better to say that Klaus just once as he imagines that such
> patches have more opportunities to become integrated into VDR.

I think Klaus sometimes underestimates the number of VDR users
(especially North American), their setups, and possibly not aware of
their/our needs.   In all honestly the number of users I see on the
forums & this mailing list don't even come close to accurately
representing the real number of users.  It can be hard sometimes to
imagine different setup needs when your sample pool is relatively
small by comparison.  That's why I'm _constantly_ asking people to at
least join the mailing list and participate.  Now to figure out how to
actually make them do it! ;)

Cheers

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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Bikalexander]

I believe that GoToX and go to position is also very important. Could it be
that maybe all the patches that have been published here so far we do not
have Klaus fallen?

Is it perhaps better to say that Klaus just once as he imagines that such
patches have more opportunities to become integrated into VDR.

Sorry for my English.

2010/2/2 Bikalexander 

> Ich glaube, dass GotoX und Go to Position auch sehr wichtig ist. Kann es
> sein, dass vielleicht alle Patches die hier bis jetzt veröffentlicht wurden
> unserem Klaus nicht gefallen haben?
>
> Ist es vielleicht sinnvoller, dass Klaus einfach mal sagt wie er es sich
> vorstellt, damit solche Patches mehr Chancen haben in VDR intergriert zu
> werden.
>
> Sorry für mein English.
>
> 2010/2/2 Ian Bates 
>
> On 1 Feb 2010, at 22:24, abbe normal wrote:
>> >
>> > On 2/1/10, VDR User  wrote:
>> >> On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin 
>> wrote:
>> >>> Hi List and Klaus,
>> >>>
>> >>> It would be really nice if vdr could support diseqc setup directly in
>> >>> vdr.
>> >>>
>> >>> I don't know if this can be done by a plugin but the current solution
>> is
>> >>> difficult for endusers.
>> >>> Setting a diseqc.conf needs some knowledge in diseqc and it's
>> commands.
>> >>> A simple interface for creating a diseqc.conf can improove the
>> >>> usability of vdr!
>> >>
>> >> Personally I think adding support for multiple diseqc switches is a
>> >> more important feature as I've noticed several users asking how to do
>> >> this in VDR -- which it unfortunately doesn't support.  I think this
>> >> is actually one of the reasons some guys fumble around trying to
>> >> cascade their diseqc switches.  However, not all switches can be
>> >> cascaded and so they're left stuck.  Can't cascade, and no support for
>> >> multiple switches.
>> >>
>> >>
>> >
>> > hey guys
>> >
>> > i agree multi cards should be able to use mutli diseqc configs... or
>> > at least be able to assign them to different switches that could be
>> > used... would be nice to add more dishes and lnbs to my setup... would
>> > like to do c and ku band dvb as well as have at least 2 to 3 fixed
>> > dishes with lnbs on them now im limited to 4 max or use a very costly
>> > switch...
>> >
>> > abby
>>
>> Dear all,
>>
>> I have a diseqc-patch I that hacked together a couple of years ago
>> relating to multi-cards/multi-switches that has served my purpose well.  It
>> may not be the best way, it may even be the wrong way.  I will drag it out
>> of the VDR box for all to see but that will not be for a couple of days.
>>
>> MOTIVATION
>>
>> I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached
>> to a 4-way diseqc switch.  Despite the switches being the same model and
>> bought at the same time each one responds to a different set of diseqc
>> commands to change LNB.  IIRC one seemed to behave as a cascade of 2-way
>> switches, the other responded to the more usual commands for a 4-way switch.
>>
>> DESCRIPTION
>>
>> Enter my hack.  It allows diseqc commands to be defined on a per-card
>> basis (numbered 1, 2, ...).  How you determine which number corresponds to
>> which card is left as an exercise for the reader (hint: the margin may not
>> be big enough).  These defines are placed in 'diseqc-multi.conf' and start
>> with the card number but are otherwise the same format as those found in
>> 'diseqc.conf'.
>>
>> CONFIGURATION
>>
>> Configuration options within VDR are:
>>
>> - use only the diseqc.conf defines,
>> - use only the diseqc-multi.conf,
>> - use the disqc-multi.conf if a card definition appears otherwise use the
>> diseqc.conf defines.
>>
>> CAVEATS
>>
>> For my purpose this patch works well.  I am aware there exist other
>> multi-satellite/multi-card patches that may address a similar problem but I
>> haven't used them.
>>
>> You'll have to wait a couple of days before I can pull it off my vdr box.
>>  Current version works with vdr-1.7.11.  This patch has survived with
>> minimal/no changes from at least the first vdr-1.6 releases.
>>
>>
>> Sorry to whet your appetites without satiating them.
>>
>>
>> Ian.
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Bikalexander]

Ich glaube, dass GotoX und Go to Position auch sehr wichtig ist. Kann es
sein, dass vielleicht alle Patches die hier bis jetzt veröffentlicht wurden
unserem Klaus nicht gefallen haben?

Ist es vielleicht sinnvoller, dass Klaus einfach mal sagt wie er es sich
vorstellt, damit solche Patches mehr Chancen haben in VDR intergriert zu
werden.

Sorry für mein English.

2010/2/2 Ian Bates 

> On 1 Feb 2010, at 22:24, abbe normal wrote:
> >
> > On 2/1/10, VDR User  wrote:
> >> On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin 
> wrote:
> >>> Hi List and Klaus,
> >>>
> >>> It would be really nice if vdr could support diseqc setup directly in
> >>> vdr.
> >>>
> >>> I don't know if this can be done by a plugin but the current solution
> is
> >>> difficult for endusers.
> >>> Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
> >>> A simple interface for creating a diseqc.conf can improove the
> >>> usability of vdr!
> >>
> >> Personally I think adding support for multiple diseqc switches is a
> >> more important feature as I've noticed several users asking how to do
> >> this in VDR -- which it unfortunately doesn't support.  I think this
> >> is actually one of the reasons some guys fumble around trying to
> >> cascade their diseqc switches.  However, not all switches can be
> >> cascaded and so they're left stuck.  Can't cascade, and no support for
> >> multiple switches.
> >>
> >>
> >
> > hey guys
> >
> > i agree multi cards should be able to use mutli diseqc configs... or
> > at least be able to assign them to different switches that could be
> > used... would be nice to add more dishes and lnbs to my setup... would
> > like to do c and ku band dvb as well as have at least 2 to 3 fixed
> > dishes with lnbs on them now im limited to 4 max or use a very costly
> > switch...
> >
> > abby
>
> Dear all,
>
> I have a diseqc-patch I that hacked together a couple of years ago relating
> to multi-cards/multi-switches that has served my purpose well.  It may not
> be the best way, it may even be the wrong way.  I will drag it out of the
> VDR box for all to see but that will not be for a couple of days.
>
> MOTIVATION
>
> I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached to
> a 4-way diseqc switch.  Despite the switches being the same model and bought
> at the same time each one responds to a different set of diseqc commands to
> change LNB.  IIRC one seemed to behave as a cascade of 2-way switches, the
> other responded to the more usual commands for a 4-way switch.
>
> DESCRIPTION
>
> Enter my hack.  It allows diseqc commands to be defined on a per-card basis
> (numbered 1, 2, ...).  How you determine which number corresponds to which
> card is left as an exercise for the reader (hint: the margin may not be big
> enough).  These defines are placed in 'diseqc-multi.conf' and start with the
> card number but are otherwise the same format as those found in
> 'diseqc.conf'.
>
> CONFIGURATION
>
> Configuration options within VDR are:
>
> - use only the diseqc.conf defines,
> - use only the diseqc-multi.conf,
> - use the disqc-multi.conf if a card definition appears otherwise use the
> diseqc.conf defines.
>
> CAVEATS
>
> For my purpose this patch works well.  I am aware there exist other
> multi-satellite/multi-card patches that may address a similar problem but I
> haven't used them.
>
> You'll have to wait a couple of days before I can pull it off my vdr box.
>  Current version works with vdr-1.7.11.  This patch has survived with
> minimal/no changes from at least the first vdr-1.6 releases.
>
>
> Sorry to whet your appetites without satiating them.
>
>
> Ian.
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[Ian Bates]

On 1 Feb 2010, at 22:24, abbe normal wrote:
> 
> On 2/1/10, VDR User  wrote:
>> On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin  wrote:
>>> Hi List and Klaus,
>>> 
>>> It would be really nice if vdr could support diseqc setup directly in
>>> vdr.
>>> 
>>> I don't know if this can be done by a plugin but the current solution is
>>> difficult for endusers.
>>> Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
>>> A simple interface for creating a diseqc.conf can improove the
>>> usability of vdr!
>> 
>> Personally I think adding support for multiple diseqc switches is a
>> more important feature as I've noticed several users asking how to do
>> this in VDR -- which it unfortunately doesn't support.  I think this
>> is actually one of the reasons some guys fumble around trying to
>> cascade their diseqc switches.  However, not all switches can be
>> cascaded and so they're left stuck.  Can't cascade, and no support for
>> multiple switches.
>> 
>> 
> 
> hey guys
> 
> i agree multi cards should be able to use mutli diseqc configs... or
> at least be able to assign them to different switches that could be
> used... would be nice to add more dishes and lnbs to my setup... would
> like to do c and ku band dvb as well as have at least 2 to 3 fixed
> dishes with lnbs on them now im limited to 4 max or use a very costly
> switch...
> 
> abby

Dear all,

I have a diseqc-patch I that hacked together a couple of years ago relating to 
multi-cards/multi-switches that has served my purpose well.  It may not be the 
best way, it may even be the wrong way.  I will drag it out of the VDR box for 
all to see but that will not be for a couple of days.

MOTIVATION

I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached to a 
4-way diseqc switch.  Despite the switches being the same model and bought at 
the same time each one responds to a different set of diseqc commands to change 
LNB.  IIRC one seemed to behave as a cascade of 2-way switches, the other 
responded to the more usual commands for a 4-way switch.

DESCRIPTION

Enter my hack.  It allows diseqc commands to be defined on a per-card basis 
(numbered 1, 2, ...).  How you determine which number corresponds to which card 
is left as an exercise for the reader (hint: the margin may not be big enough). 
 These defines are placed in 'diseqc-multi.conf' and start with the card number 
but are otherwise the same format as those found in 'diseqc.conf'.

CONFIGURATION

Configuration options within VDR are:

- use only the diseqc.conf defines, 
- use only the diseqc-multi.conf, 
- use the disqc-multi.conf if a card definition appears otherwise use the 
diseqc.conf defines.

CAVEATS

For my purpose this patch works well.  I am aware there exist other 
multi-satellite/multi-card patches that may address a similar problem but I 
haven't used them.

You'll have to wait a couple of days before I can pull it off my vdr box.  
Current version works with vdr-1.7.11.  This patch has survived with minimal/no 
changes from at least the first vdr-1.6 releases.


Sorry to whet your appetites without satiating them.


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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[abbe normal]

hey guys

i agree multi cards should be able to use mutli diseqc configs... or
at least be able to assign them to different switches that could be
used... would be nice to add more dishes and lnbs to my setup... would
like to do c and ku band dvb as well as have at least 2 to 3 fixed
dishes with lnbs on them now im limited to 4 max or use a very costly
switch...

abby

On 2/1/10, VDR User  wrote:
> On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin  wrote:
>> Hi List and Klaus,
>>
>> It would be really nice if vdr could support diseqc setup directly in
>> vdr.
>>
>> I don't know if this can be done by a plugin but the current solution is
>> difficult for endusers.
>> Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
>> A simple interface for creating a diseqc.conf can improove the
>> usability of vdr!
>
> Personally I think adding support for multiple diseqc switches is a
> more important feature as I've noticed several users asking how to do
> this in VDR -- which it unfortunately doesn't support.  I think this
> is actually one of the reasons some guys fumble around trying to
> cascade their diseqc switches.  However, not all switches can be
> cascaded and so they're left stuck.  Can't cascade, and no support for
> multiple switches.
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] feature request easy diseqc setup and channelscan for vdr

[VDR User]

On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin  wrote:
> Hi List and Klaus,
>
> It would be really nice if vdr could support diseqc setup directly in
> vdr.
>
> I don't know if this can be done by a plugin but the current solution is
> difficult for endusers.
> Setting a diseqc.conf needs some knowledge in diseqc and it's commands.
> A simple interface for creating a diseqc.conf can improove the
> usability of vdr!

Personally I think adding support for multiple diseqc switches is a
more important feature as I've noticed several users asking how to do
this in VDR -- which it unfortunately doesn't support.  I think this
is actually one of the reasons some guys fumble around trying to
cascade their diseqc switches.  However, not all switches can be
cascaded and so they're left stuck.  Can't cascade, and no support for
multiple switches.

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

Re: [vdr] feature request

[Walter Koch]

Moin,

> I mean if I press Info and get the current EPG ("Now"), it would be nice a
> one-key way to see what is "Next" on this same channel.

The yellow button does the trick. At least with my (patchy) 1.6.0-vdr.

Gruss,
  Walter


-- 
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


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

Re: [vdr] feature request

[martinez]

I mean if I press Info and get the current EPG ("Now"), it would be nice a
one-key way to see what is "Next" on this same channel.

At the moment when you are looking at "Now" and want to see what is "Next" you
have to press Exit, then down, then Ok (3 key presses)

Since "Left" and "Right" are used for scrolling, perhaps the PrevChannel key
could be assigned to switch between "Next" and "Now"

On 30.05.2009 18:41, marti...@embl.de wrote:
> When looking at a given channels EPG ?Now? one click access to ?Next
> ? would
> be nice.

What exactly do you mean?
The green button does switch between "Now" and "Next" in the "Schedule"
menu.



> In Enigma (As a reference) this is implemented with left and right (going f
> rom
> now to next and back)

"Left" and "Right" are used to scroll up and down, respectively, in VDR.

Klaus

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

Re: [vdr] feature request

[Klaus Schmidinger]

On 30.05.2009 18:41, marti...@embl.de wrote:
> When looking at a given channels EPG ´Now´ one click access to ´Next
> ´ would
> be nice.

What exactly do you mean?
The green button does switch between "Now" and "Next" in the "Schedule"
menu.

> In Enigma (As a reference) this is implemented with left and right (going f
> rom
> now to next and back)

"Left" and "Right" are used to scroll up and down, respectively, in VDR.

Klaus

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

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[Pasi Juppo]

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

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

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[Rolf Ahrenberg]

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.


BR,
--
rofa

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

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[Pasi Juppo]

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.

  

commands:  jump
parameter: +/- num of seconds

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

Br, Pasi

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

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[Rolf Ahrenberg]

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.


BR,
--
rofa

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

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[Laz]

On Saturday 03 February 2007 18:03, VDR User wrote:
> On 2/2/07, martin <[EMAIL PROTECTED]> 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

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[VDR User]

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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[VDR User]

On 2/2/07, martin <[EMAIL PROTECTED]> 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;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[Klaus Schmidinger]

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

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

Re: [vdr] Feature Request: MySQL interface for EPG/configuration

[Andreas Brachold]

Hi,

Am Samstag, den 09.09.2006, 11:51 +0200 schrieb Rene Bartsch:
> if the configuration (channels, transponders, options) and EPG would
> be stored in a MySQL-DB other applications could easily use that data
> instead of doing expensive scans of the files again and again.

There exits XXV, it store many vdr data at mysql-tables.
It could use as http, telnet or soap server.

Enjoy,
Andreas

[1] http://xpix.dieserver.de/content
[2] http://www.linuxtv.org/vdrwiki/index.php/Xxv
[3] http://www.vdr-wiki.de/wiki/index.php/Xxv



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

Re: [vdr] Feature Request: MySQL interface for EPG/configuration

[Rene Bartsch]

> It does have the added overheads of running MySQL on what might be a
> low-power
> system, slower startup, etc. Then again, reading large amounts of EPG
> data,
> etc. from what can be huge flat files should improve things!
>
> Maybe it could be a build-time option...
>

Maybe embedded SQL can help you?

Renne



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

Re: [vdr] Feature Request: MySQL interface for EPG/configuration

[Rene Bartsch]

> Rene Bartsch wrote:
>> if the configuration (channels, transponders, options) and EPG would be
>> stored in a MySQL-DB other applications could easily use that data
>> instead
>> of doing expensive scans of the files again and again.
>>
>> Maybe there could be a compiler switch or even a command-line option for
>> VDR to switch between file and SQL mode.
>>
>>
> this could even solve some problems regarding synchronisation/thread
> safeness. But IMHO this sounds like a feature of VDR 2.0 ;-)
>

For a start one could just use the same DB-tables and structures as the
current EPG/configuraton files are. That way the class writing the files
could be easily inherited with the writing functions overwritten by
functions with MySQL queries. A compiler switch would then select between
the two classes at compile time. Unfortunately I don't have enough C++
skills to do it myself.

Renne



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

Re: [vdr] Feature Request: MySQL interface for EPG/configuration

[Laz]

On Saturday 09 September 2006 12:09, Christian Wieninger wrote:
> Rene Bartsch wrote:
> > if the configuration (channels, transponders, options) and EPG would be
> > stored in a MySQL-DB other applications could easily use that data
> > instead of doing expensive scans of the files again and again.
> >
> > Maybe there could be a compiler switch or even a command-line option for
> > VDR to switch between file and SQL mode.
>
> this could even solve some problems regarding synchronisation/thread
> safeness. But IMHO this sounds like a feature of VDR 2.0 ;-)

It does have the added overheads of running MySQL on what might be a low-power 
system, slower startup, etc. Then again, reading large amounts of EPG data, 
etc. from what can be huge flat files should improve things!

Maybe it could be a build-time option...

Laz

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

Re: [vdr] Feature Request: MySQL interface for EPG/configuration

[Christian Wieninger]

Rene Bartsch wrote:

if the configuration (channels, transponders, options) and EPG would be
stored in a MySQL-DB other applications could easily use that data instead
of doing expensive scans of the files again and again.

Maybe there could be a compiler switch or even a command-line option for
VDR to switch between file and SQL mode.

  
this could even solve some problems regarding synchronisation/thread 
safeness. But IMHO this sounds like a feature of VDR 2.0 ;-)


BR,

Christian


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

Re: [vdr] Feature Request: MySQL interface for EPG/configuration

[Lauri Tischler]

Rene Bartsch wrote:

Hi,

if the configuration (channels, transponders, options) and EPG would be
stored in a MySQL-DB other applications could easily use that data instead
of doing expensive scans of the files again and again.

Maybe there could be a compiler switch or even a command-line option for
VDR to switch between file and SQL mode.


Could be very usefull if VDR ever evolves to real client/server
system.   For simple STB, I'm not so sure.


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