Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Am 27.03.2011 16:45, schrieb Klaus Schmidinger:
> Can you please rewrite your patch so that it keeps the original 'd'
> variable? I liked the fact that the 'nextUpdate' variable was incremented
> in *one* place, and not in several places. Made the whole thing more
> transparent to me. Besides, I could then see what you have *actually*
> changed ;-)
Another example on how coding style is a matter of taste. One of the
first things I changed was the removing of the d variable that is IMHO
superfluous, doesn't have an unique meaning (file age in seconds and
time to next check), and no descriptive name. ;)
Anyway, I've rewritten it to match your original patch more closely.
Actually I'm surprised how similar they got again, I had some evolution
steps that were completely different.
Attached is the rewritten patch as updatemarks-4, and for your
convenience a diff between updatemarks-2 and updatemarks-4 that shows
the differences more closely.
Cheers,
Udo
diff -Naurp vdr-1.7.17-orig/recording.c vdr-1.7.17-updatemarks-4/recording.c
--- vdr-1.7.17-orig/recording.c 2011-02-27 14:35:20.0 +0100
+++ vdr-1.7.17-updatemarks-4/recording.c 2011-04-03 15:05:16.0 +0200
@@ -1270,19 +1270,31 @@ bool cMarks::Load(const char *RecordingF
{
fileName = AddDirectory(RecordingFileName, IsPesRecording ? MARKSFILESUFFIX ".vdr" : MARKSFILESUFFIX);
framesPerSecond = FramesPerSecond;
- lastUpdate = 0;
+ nextUpdate = 0;
lastFileTime = -1; // the first call to Load() must take place!
+ lastChange = 0;
return Update();
}
bool cMarks::Update(void)
{
time_t t = time(NULL);
- if (t - lastUpdate > MARKSUPDATEDELTA) {
- lastUpdate = t;
- t = LastModifiedTime(fileName);
- if (t > lastFileTime) {
-lastFileTime = t;
+ if (t > nextUpdate) {
+ time_t LastModified = LastModifiedTime(fileName);
+ if (LastModified != lastFileTime) // Change detected, or first run
+lastChange = LastModified>0 ? LastModified : t;
+ int d = t - lastChange;
+ if (d < 60)
+d = 1; // check frequently if the file has just been modified
+ else if (d < 3600)
+d = 10; // older files are checked less frequently
+ else
+d /= 360; // phase out checking for very old files
+ nextUpdate = t + d;
+ if (LastModified != lastFileTime) { // Change detected, or first run
+lastFileTime = LastModified;
+if (lastFileTime == t)
+ lastFileTime--; // Make sure we don't miss updates in the remaining second
cMutexLock MutexLock(&MutexMarkFramesPerSecond);
MarkFramesPerSecond = framesPerSecond;
if (cConfig::Load(fileName)) {
diff -Naurp vdr-1.7.17-orig/recording.h vdr-1.7.17-updatemarks-4/recording.h
--- vdr-1.7.17-orig/recording.h 2011-02-27 13:48:21.0 +0100
+++ vdr-1.7.17-updatemarks-4/recording.h 2011-04-03 14:57:20.0 +0200
@@ -192,8 +192,9 @@ class cMarks : public cConfig {
private:
cString fileName;
double framesPerSecond;
- time_t lastUpdate;
+ time_t nextUpdate;
time_t lastFileTime;
+ time_t lastChange;
public:
bool Load(const char *RecordingFileName, double FramesPerSecond = DEFAULTFRAMESPERSECOND, bool IsPesRecording = false);
bool Update(void);
diff -Naurp vdr-1.7.17-updatemarks-2/recording.c vdr-1.7.17-updatemarks-4/recording.c
--- vdr-1.7.17-updatemarks-2/recording.c 2011-04-03 14:59:24.0 +0200
+++ vdr-1.7.17-updatemarks-4/recording.c 2011-04-03 15:05:16.0 +0200
@@ -1272,6 +1272,7 @@ bool cMarks::Load(const char *RecordingF
framesPerSecond = FramesPerSecond;
nextUpdate = 0;
lastFileTime = -1; // the first call to Load() must take place!
+ lastChange = 0;
return Update();
}
@@ -1280,16 +1281,9 @@ bool cMarks::Update(void)
time_t t = time(NULL);
if (t > nextUpdate) {
time_t LastModified = LastModifiedTime(fileName);
- int d;
- if (LastModified > 0) // the file exists
-d = t - LastModified;
- else { // the file doesn't exist
-if (lastFileTime <= 0) {
- lastFileTime = t - 2; // -2 makes sure we don't miss an update within the very same second
- LastModified = t; // make sure we run into the actual Load() below
- }
-d = t - lastFileTime;
-}
+ if (LastModified != lastFileTime) // Change detected, or first run
+lastChange = LastModified>0 ? LastModified : t;
+ int d = t - lastChange;
if (d < 60)
d = 1; // check frequently if the file has just been modified
else if (d < 3600)
@@ -1297,8 +1291,10 @@ bool cMarks::Update(void)
else
d /= 360; // phase out checking for very old files
nextUpdate = t + d;
- if (LastModified > lastFileTime) {
+ if (LastModified != lastFileTime) { // Change detected, or first run
lastFileTime = LastModified;
+if (lastFileTime == t)
+ lastFileTime--; // Make sure we don't miss updates in the remaining second
cMutexLock MutexLock(&MutexMarkFra
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Am Montag, 28. März 2011, um 18:17:50 schrieb Klaus Schmidinger:
> void cRecorder::Action(void)
> {
>...
>if (frameDetector->Synced()) {
> if (!InfoWritten) {
> cRecordingInfo RecordingInfo(recordingName);
> if (RecordingInfo.Read()) {
> if (frameDetector->FramesPerSecond() > 0 &&
> !DoubleEqual(RecordingInfo.FramesPerSecond(),
> frameDetector->FramesPerSecond())) {
Thank you, this was the part i was looking for. Read() always returned false
for me because of a wrong patch. Now i fixed that.
cheers,
Tim
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 28.03.2011 11:24, Tim wrote: Am Samstag, 19. März 2011, um 13:02:02 schrieb Klaus Schmidinger: - Fixed detecting frames on channels that broadcast with 50 or 60 fps. I just made a recording from "arte HD" with VDR 1.7.17 and everything worked fine. It played correctly (on a TT-S2 6400 prototype), the current and total times displayed by the progress display were correct and I was able to place and move an editing mark with the picture getting updated just fine. For me the frame detection works fine, but still the wrong framerate is written to the info file (always F 25 is written there). Maybe some nasty patch is breaking this for me, but i don't find it. Is this really working correct for you? Sorry, forgot to add this in my previous post. I just did another recording on "arte HD", and this is the info file I got: C S19.2E-1-1011-11120 arte HD E 35957 1301328600 3000 4E 6 T Mit Schirm, Charme und Melone S Fit für Mord D Hochkarätige Manager werden ermordet und von ihren kompetenten Sekretärinnen vertreten, die die Geschäfte nahtlos weiterführen. Alle Damen sind Mitglieder in einem Fitnessclub, in dem sich auch bald Emma Peel anmeldet. G 15 30 33 F0 X 5 0B deu HD-Video X 2 03 deu stereo X 4 42 deu Dolby Digital 2.0 X 3 12 deu DVB-Untertitel X 2 03 fra französisch X 3 03 fra V 1301328600 F 50 P 50 L 50 Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 28.03.2011 11:24, Tim wrote:
Am Samstag, 19. März 2011, um 13:02:02 schrieb Klaus Schmidinger:
- Fixed detecting frames on channels that broadcast with 50 or 60 fps.
I just made a recording from "arte HD" with VDR 1.7.17 and everything
worked fine. It played correctly (on a TT-S2 6400 prototype), the current
and total times displayed by the progress display were correct and I was
able to place and move an editing mark with the picture getting updated
just fine.
For me the frame detection works fine, but still the wrong framerate is written
to the info file (always F 25 is written there).
Maybe some nasty patch is breaking this for me, but i don't find it. Is this
really working correct for you?
Can you give me a hint where the information is transferred from the
cFrameDetector to cRecordingInfo?
void cRecorder::Action(void)
{
...
if (frameDetector->Synced()) {
if (!InfoWritten) {
cRecordingInfo RecordingInfo(recordingName);
if (RecordingInfo.Read()) {
if (frameDetector->FramesPerSecond() > 0 &&
!DoubleEqual(RecordingInfo.FramesPerSecond(), frameDetector->FramesPerSecond())) {
RecordingInfo.SetFramesPerSecond(frameDetector->FramesPerSecond());
RecordingInfo.Write();
Recordings.UpdateByName(recordingName);
}
}
InfoWritten = true;
}
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On Mon, Mar 28, 2011 at 2:24 AM, Tim wrote: >> >> - Fixed detecting frames on channels that broadcast with 50 or 60 fps. > >> I just made a recording from "arte HD" with VDR 1.7.17 and everything >> worked fine. It played correctly (on a TT-S2 6400 prototype), the current >> and total times displayed by the progress display were correct and I was >> able to place and move an editing mark with the picture getting updated >> just fine. > > For me the frame detection works fine, but still the wrong framerate is > written > to the info file (always F 25 is written there). > Maybe some nasty patch is breaking this for me, but i don't find it. Is this > really working correct for you? > Can you give me a hint where the information is transferred from the > cFrameDetector to cRecordingInfo? I'll jump in and say that all my new HD recordings have the correct framerate (mixture of 59.94 and 29.97) in their relative "info" files. I suspect some patch you're using is breaking this and you've mentioned. The good news is it should be pretty easy to figure out which one. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Am Samstag, 19. März 2011, um 13:02:02 schrieb Klaus Schmidinger: > >> - Fixed detecting frames on channels that broadcast with 50 or 60 fps. > I just made a recording from "arte HD" with VDR 1.7.17 and everything > worked fine. It played correctly (on a TT-S2 6400 prototype), the current > and total times displayed by the progress display were correct and I was > able to place and move an editing mark with the picture getting updated > just fine. For me the frame detection works fine, but still the wrong framerate is written to the info file (always F 25 is written there). Maybe some nasty patch is breaking this for me, but i don't find it. Is this really working correct for you? Can you give me a hint where the information is transferred from the cFrameDetector to cRecordingInfo? regards, Tim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 20.03.2011 21:07, Udo Richter wrote: Am 20.03.2011 13:31, schrieb Klaus Schmidinger: On 20.03.2011 12:46, Klaus Schmidinger wrote: I have attached a patch that implements this. Would this be ok? Sorry, there was a line missing that makes sure the initial load takes place. Attached is a revised version of the patch. You're too fast for me :D I like the general idea, but I have some points about it: - Disappearing marks or replacing marks by older versions is not detected. Ok, that would be the if (LastModified != lastFileTime) change, agreed. - Double updates within one second may get lost. - I don't think that it hurts to poll every 10 seconds, so IMHO we can drop the 3600s check. I'd still like to phase that out, because for such old marks files it just doesn't make sense to poll them any more. - When in pause mode with the progress bar on OSD, the OSD doesn't get updated when the marks get reloaded. After some iterations I've ended with the attached patch that fixes the first two issues, and is less messy with lastFileTime. Any change of file time will be detected, and the new lastChange covers cases where no marks file is present. There's a small gap with the lastFileTime == t check on NFS volumes with unsynced clocks, but thats another story. The third point is a matter of taste, and the fourth is not that important. Can you please rewrite your patch so that it keeps the original 'd' variable? I liked the fact that the 'nextUpdate' variable was incremented in *one* place, and not in several places. Made the whole thing more transparent to me. Besides, I could then see what you have *actually* changed ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Am 20.03.2011 13:31, schrieb Klaus Schmidinger:
> On 20.03.2011 12:46, Klaus Schmidinger wrote:
>> I have attached a patch that implements this.
>> Would this be ok?
>
> Sorry, there was a line missing that makes sure the initial load
> takes place. Attached is a revised version of the patch.
You're too fast for me :D
I like the general idea, but I have some points about it:
- Disappearing marks or replacing marks by older versions is not detected.
- Double updates within one second may get lost.
- I don't think that it hurts to poll every 10 seconds, so IMHO we can
drop the 3600s check.
- When in pause mode with the progress bar on OSD, the OSD doesn't get
updated when the marks get reloaded.
After some iterations I've ended with the attached patch that fixes the
first two issues, and is less messy with lastFileTime. Any change of
file time will be detected, and the new lastChange covers cases where no
marks file is present. There's a small gap with the lastFileTime == t
check on NFS volumes with unsynced clocks, but thats another story.
The third point is a matter of taste, and the fourth is not that important.
Cheers,
Udo
diff -Naurp vdr-1.7.17-orig/recording.c vdr-1.7.17/recording.c
--- vdr-1.7.17-orig/recording.c 2011-02-27 14:35:20.0 +0100
+++ vdr-1.7.17/recording.c 2011-03-20 20:46:01.0 +0100
@@ -1270,19 +1270,30 @@ bool cMarks::Load(const char *RecordingF
{
fileName = AddDirectory(RecordingFileName, IsPesRecording ? MARKSFILESUFFIX ".vdr" : MARKSFILESUFFIX);
framesPerSecond = FramesPerSecond;
- lastUpdate = 0;
+ nextUpdate = 0;
lastFileTime = -1; // the first call to Load() must take place!
+ lastChange = 0;
return Update();
}
bool cMarks::Update(void)
{
time_t t = time(NULL);
- if (t - lastUpdate > MARKSUPDATEDELTA) {
- lastUpdate = t;
- t = LastModifiedTime(fileName);
- if (t > lastFileTime) {
-lastFileTime = t;
+ if (t > nextUpdate) {
+ time_t LastModified = LastModifiedTime(fileName);
+ if (LastModified != lastFileTime) // Change detected, or first run
+lastChange = LastModified>0 ? LastModified : t;
+ if (t - lastChange < 60)
+nextUpdate = t + 1; // check frequently if the file has just been modified
+ else if (t - lastChange < 3600)
+nextUpdate = t + 10; // older files are checked less frequently
+ else
+nextUpdate = t + (t - lastChange)/360; // phase out checking for very old files
+
+ if (LastModified != lastFileTime) { // Change detected, or first run
+lastFileTime = LastModified;
+if (lastFileTime == t)
+ lastFileTime--; // Make sure we don't miss updates in the remaining second
cMutexLock MutexLock(&MutexMarkFramesPerSecond);
MarkFramesPerSecond = framesPerSecond;
if (cConfig::Load(fileName)) {
diff -Naurp vdr-1.7.17-orig/recording.h vdr-1.7.17/recording.h
--- vdr-1.7.17-orig/recording.h 2011-02-27 13:48:21.0 +0100
+++ vdr-1.7.17/recording.h 2011-03-20 19:35:27.0 +0100
@@ -192,8 +192,9 @@ class cMarks : public cConfig {
private:
cString fileName;
double framesPerSecond;
- time_t lastUpdate;
+ time_t nextUpdate;
time_t lastFileTime;
+ time_t lastChange;
public:
bool Load(const char *RecordingFileName, double FramesPerSecond = DEFAULTFRAMESPERSECOND, bool IsPesRecording = false);
bool Update(void);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 20.03.2011 12:46, Klaus Schmidinger wrote:
> On 19.03.2011 22:42, Klaus Schmidinger wrote:
>> On 19.03.2011 21:56, Udo Richter wrote:
>>> Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
- While replaying, the editing marks are now updated every 10 seconds
(based on a
patch from Manuel Reimer).
>>>
>>> Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I
>>> only used the marks reloading. (As a good-bye, I've posted an updated
>>> jumpplay at [1]).
>>>
>>> However, the VDR version also has the slow update speed of once every 10
>>> seconds that I don't like. Especially after editing, I usually
>>> immediately switch to the edited recording to check the result, and then
>>> have to either wait 10 seconds for all marks to appear, or re-start the
>>> replay to get updated marks. (With hard link cutter, editing is usually
>>> done in less than 10 seconds.)
>>>
>>> As a solution, I thought it would be a good idea to reload the marks
>>> file whenever the index file gets updated. Unfortunately, this is more
>>> complicated than I thought, because the marks reside in cReplayControl,
>>> while the index is in a cDvbPlayer which is owned by cDvbPlayerControl.
>>> There is no direct access to the index from cReplayControl.
>>>
>>> Polling for number of total frames via GetIndex() would work, as
>>> cReplayControl::ShowProgress does - but only if the editing OSD is
>>> visible. So add another polling of GetIndex(), and another lastTotal to
>>> check for changes? Not very elegant. The alternative would be some extra
>>> rewrites...
>>>
>>>
>>> Any thoughts on that?
>>
>> How about taking the age of the marks file into account?
>> Like, when checking whether the file has been changed, calculate
>> the age of the file (tm) and schedule the next check for "now + f(tm)".
>> That way, a file that has just been updated will be checked again
>> very soon, while an old file will only be checked rarely.
>> Ages under one minute could be treated as "one second", ages under
>> one hour as "10 seconds" and anything older could just result
>> in not rereading the marks file (since it's rather unlikely that
>> it will change once it's grown that old).
>
> I have attached a patch that implements this.
> Would this be ok?
Sorry, there was a line missing that makes sure the initial load
takes place. Attached is a revised version of the patch.
Klaus
===
RCS file: ./RCS/recording.c
retrieving revision 2.26
diff -u -b -r2.26 ./recording.c
--- ./recording.c 2011/02/27 13:35:20 2.26
+++ ./recording.c 2011/03/20 12:25:00
@@ -1270,7 +1270,7 @@
{
fileName = AddDirectory(RecordingFileName, IsPesRecording ? MARKSFILESUFFIX ".vdr" : MARKSFILESUFFIX);
framesPerSecond = FramesPerSecond;
- lastUpdate = 0;
+ nextUpdate = 0;
lastFileTime = -1; // the first call to Load() must take place!
return Update();
}
@@ -1278,11 +1278,27 @@
bool cMarks::Update(void)
{
time_t t = time(NULL);
- if (t - lastUpdate > MARKSUPDATEDELTA) {
- lastUpdate = t;
- t = LastModifiedTime(fileName);
- if (t > lastFileTime) {
-lastFileTime = t;
+ if (t > nextUpdate) {
+ time_t LastModified = LastModifiedTime(fileName);
+ int d;
+ if (LastModified > 0) // the file exists
+d = t - LastModified;
+ else { // the file doesn't exist
+if (lastFileTime <= 0) {
+ lastFileTime = t - 2; // -2 makes sure we don't miss an update within the very same second
+ LastModified = t; // make sure we run into the actual Load() below
+ }
+d = t - lastFileTime;
+}
+ if (d < 60)
+d = 1; // check frequently if the file has just been modified
+ else if (d < 3600)
+d = 10; // older files are checked less frequently
+ else
+d /= 360; // phase out checking for very old files
+ nextUpdate = t + d;
+ if (LastModified > lastFileTime) {
+lastFileTime = LastModified;
cMutexLock MutexLock(&MutexMarkFramesPerSecond);
MarkFramesPerSecond = framesPerSecond;
if (cConfig::Load(fileName)) {
===
RCS file: ./RCS/recording.h
retrieving revision 2.16
diff -u -b -r2.16 ./recording.h
--- ./recording.h 2011/02/27 12:48:21 2.16
+++ ./recording.h 2011/03/20 10:33:30
@@ -192,7 +192,7 @@
private:
cString fileName;
double framesPerSecond;
- time_t lastUpdate;
+ time_t nextUpdate;
time_t lastFileTime;
public:
bool Load(const char *RecordingFileName, double FramesPerSecond = DEFAULTFRAMESPERSECOND, bool IsPesRecording = false);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 19.03.2011 22:42, Klaus Schmidinger wrote:
> On 19.03.2011 21:56, Udo Richter wrote:
>> Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
>>> - While replaying, the editing marks are now updated every 10 seconds
>>> (based on a
>>> patch from Manuel Reimer).
>>
>> Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I
>> only used the marks reloading. (As a good-bye, I've posted an updated
>> jumpplay at [1]).
>>
>> However, the VDR version also has the slow update speed of once every 10
>> seconds that I don't like. Especially after editing, I usually
>> immediately switch to the edited recording to check the result, and then
>> have to either wait 10 seconds for all marks to appear, or re-start the
>> replay to get updated marks. (With hard link cutter, editing is usually
>> done in less than 10 seconds.)
>>
>> As a solution, I thought it would be a good idea to reload the marks
>> file whenever the index file gets updated. Unfortunately, this is more
>> complicated than I thought, because the marks reside in cReplayControl,
>> while the index is in a cDvbPlayer which is owned by cDvbPlayerControl.
>> There is no direct access to the index from cReplayControl.
>>
>> Polling for number of total frames via GetIndex() would work, as
>> cReplayControl::ShowProgress does - but only if the editing OSD is
>> visible. So add another polling of GetIndex(), and another lastTotal to
>> check for changes? Not very elegant. The alternative would be some extra
>> rewrites...
>>
>>
>> Any thoughts on that?
>
> How about taking the age of the marks file into account?
> Like, when checking whether the file has been changed, calculate
> the age of the file (tm) and schedule the next check for "now + f(tm)".
> That way, a file that has just been updated will be checked again
> very soon, while an old file will only be checked rarely.
> Ages under one minute could be treated as "one second", ages under
> one hour as "10 seconds" and anything older could just result
> in not rereading the marks file (since it's rather unlikely that
> it will change once it's grown that old).
I have attached a patch that implements this.
Would this be ok?
Klaus
===
RCS file: ./RCS/recording.c
retrieving revision 2.26
diff -u -b -r2.26 ./recording.c
--- ./recording.c 2011/02/27 13:35:20 2.26
+++ ./recording.c 2011/03/20 11:44:29
@@ -1270,7 +1270,7 @@
{
fileName = AddDirectory(RecordingFileName, IsPesRecording ? MARKSFILESUFFIX ".vdr" : MARKSFILESUFFIX);
framesPerSecond = FramesPerSecond;
- lastUpdate = 0;
+ nextUpdate = 0;
lastFileTime = -1; // the first call to Load() must take place!
return Update();
}
@@ -1278,11 +1278,25 @@
bool cMarks::Update(void)
{
time_t t = time(NULL);
- if (t - lastUpdate > MARKSUPDATEDELTA) {
- lastUpdate = t;
- t = LastModifiedTime(fileName);
- if (t > lastFileTime) {
-lastFileTime = t;
+ if (t > nextUpdate) {
+ time_t LastModified = LastModifiedTime(fileName);
+ int d;
+ if (LastModified > 0) // the file exists
+d = t - LastModified;
+ else { // the file doesn't exist
+if (lastFileTime <= 0)
+ lastFileTime = t - 2; // -2 makes sure we don't miss an update within the very same second
+d = t - lastFileTime;
+}
+ if (d < 60)
+d = 1; // check frequently if the file has just been modified
+ else if (d < 3600)
+d = 10; // older files are checked less frequently
+ else
+d /= 360; // phase out checking for very old files
+ nextUpdate = t + d;
+ if (LastModified > lastFileTime) {
+lastFileTime = LastModified;
cMutexLock MutexLock(&MutexMarkFramesPerSecond);
MarkFramesPerSecond = framesPerSecond;
if (cConfig::Load(fileName)) {
===
RCS file: ./RCS/recording.h
retrieving revision 2.16
diff -u -b -r2.16 ./recording.h
--- ./recording.h 2011/02/27 12:48:21 2.16
+++ ./recording.h 2011/03/20 10:33:30
@@ -192,7 +192,7 @@
private:
cString fileName;
double framesPerSecond;
- time_t lastUpdate;
+ time_t nextUpdate;
time_t lastFileTime;
public:
bool Load(const char *RecordingFileName, double FramesPerSecond = DEFAULTFRAMESPERSECOND, bool IsPesRecording = false);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 19.03.2011 21:56, Udo Richter wrote: > Am 13.03.2011 12:46, schrieb Klaus Schmidinger: >> - While replaying, the editing marks are now updated every 10 seconds (based >> on a >> patch from Manuel Reimer). > > Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I > only used the marks reloading. (As a good-bye, I've posted an updated > jumpplay at [1]). > > However, the VDR version also has the slow update speed of once every 10 > seconds that I don't like. Especially after editing, I usually > immediately switch to the edited recording to check the result, and then > have to either wait 10 seconds for all marks to appear, or re-start the > replay to get updated marks. (With hard link cutter, editing is usually > done in less than 10 seconds.) > > As a solution, I thought it would be a good idea to reload the marks > file whenever the index file gets updated. Unfortunately, this is more > complicated than I thought, because the marks reside in cReplayControl, > while the index is in a cDvbPlayer which is owned by cDvbPlayerControl. > There is no direct access to the index from cReplayControl. > > Polling for number of total frames via GetIndex() would work, as > cReplayControl::ShowProgress does - but only if the editing OSD is > visible. So add another polling of GetIndex(), and another lastTotal to > check for changes? Not very elegant. The alternative would be some extra > rewrites... > > > Any thoughts on that? How about taking the age of the marks file into account? Like, when checking whether the file has been changed, calculate the age of the file (tm) and schedule the next check for "now + f(tm)". That way, a file that has just been updated will be checked again very soon, while an old file will only be checked rarely. Ages under one minute could be treated as "one second", ages under one hour as "10 seconds" and anything older could just result in not rereading the marks file (since it's rather unlikely that it will change once it's grown that old). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Am 13.03.2011 12:46, schrieb Klaus Schmidinger: > - While replaying, the editing marks are now updated every 10 seconds (based > on a > patch from Manuel Reimer). Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I only used the marks reloading. (As a good-bye, I've posted an updated jumpplay at [1]). However, the VDR version also has the slow update speed of once every 10 seconds that I don't like. Especially after editing, I usually immediately switch to the edited recording to check the result, and then have to either wait 10 seconds for all marks to appear, or re-start the replay to get updated marks. (With hard link cutter, editing is usually done in less than 10 seconds.) As a solution, I thought it would be a good idea to reload the marks file whenever the index file gets updated. Unfortunately, this is more complicated than I thought, because the marks reside in cReplayControl, while the index is in a cDvbPlayer which is owned by cDvbPlayerControl. There is no direct access to the index from cReplayControl. Polling for number of total frames via GetIndex() would work, as cReplayControl::ShowProgress does - but only if the editing OSD is visible. So add another polling of GetIndex(), and another lastTotal to check for changes? Not very elegant. The alternative would be some extra rewrites... Any thoughts on that? Cheers, Udo [1] http://www.vdr-portal.de/board/thread.php?threadid=104863 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
In article <4d84ee1d.8090...@gmx.de> you write: >Am 19.03.2011 18:40, schrieb Juergen Lock: >> There is one remaining bug tho: After playback of a short recording >> (sd in this case, 20s or so), vdr seems to kind of hang and I have >> to kill it... Can you reproduce that? Longer recordings are not >> affected. > >This is probably an old bug: For me, VDR has always been hanging at the >end of a recording, if that recording is shorter than one minute. Takes >10 or 20 seconds, then brings you back to live view again. Its not that >annoying, as recordings are usually longer, so I've never been going on >bug hunt for this. Ah yeah, that could well be it. I also found that sometimes playback of a short recording that was played before(?) doesn't start until you hit green... (black screen or `no signal', don't remember.) Anyway, you are right, short recordings are kinda rare in real life. :) Thanx, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Am 19.03.2011 18:40, schrieb Juergen Lock: > There is one remaining bug tho: After playback of a short recording > (sd in this case, 20s or so), vdr seems to kind of hang and I have > to kill it... Can you reproduce that? Longer recordings are not > affected. This is probably an old bug: For me, VDR has always been hanging at the end of a recording, if that recording is shorter than one minute. Takes 10 or 20 seconds, then brings you back to live view again. Its not that annoying, as recordings are usually longer, so I've never been going on bug hunt for this. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
In article <201103191519.p2jfjkzw037...@triton8.kn-bremen.de> you write: >In article <4d849b3a.6060...@tvdr.de> you write: >>On 17.03.2011 22:36, Juergen Lock wrote: >>> In article <4d7caea2.9050...@tvdr.de> you write: VDR developer version 1.7.17 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. [...] - Fixed detecting frames on channels that broadcast with 50 or 60 fps. This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. [...] >>> >>> I wonder if I'm chasing a ghost there... am I really the only one >>> seeing this? I can't get this index rebuilding to work regardless >>> if I try it with old or new recordings, if I mv away the original >>> index file that was created with a recording I always get totally >>> different index files rebuilt (checked with hexdump/cmp -l) that >>> cause playbacks (via xineliboutput) to look quite corrupted immediately >>> and make vdr-sxfe hang at eof too. >>> >>> This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, >>> FreeBSD 8.2/amd64, using these ports: >>> >>> http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar >>> >>> (originally noticed with recordings from arte hd on 19.2E, but also >>> reproduced with new short sd recordings, even from dvb-t.) >> >>I just made a recording from "arte HD" with VDR 1.7.17 and everything worked >>fine. >>It played correctly (on a TT-S2 6400 prototype), the current and total >>times displayed by the progress display were correct and I was able to >>place and move an editing mark with the picture getting updated just >>fine. > >So it also works when you stop vdr, mv the recording's index >file away and then let vdr regenerate it? Could this be an >amd64/x86_64 issue? Found the problem: The FreeBSD patches disable USE_FADVISE in tools.c, and there was an #else clause missing when its not defined: --- tools.c.orig +++ tools.c @@ -1669,6 +1669,9 @@ ssize_t cUnbufferedFile::Read(void *Data } } lastpos = curpos; +#else + if (bytesRead > 0) +curpos += bytesRead; #endif return bytesRead; } There is one remaining bug tho: After playback of a short recording (sd in this case, 20s or so), vdr seems to kind of hang and I have to kill it... Can you reproduce that? Longer recordings are not affected. Thanx, :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 19.03.2011 16:19, Juergen Lock wrote: > In article <4d849b3a.6060...@tvdr.de> you write: >> On 17.03.2011 22:36, Juergen Lock wrote: >>> In article <4d7caea2.9050...@tvdr.de> you write: VDR developer version 1.7.17 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. [...] - Fixed detecting frames on channels that broadcast with 50 or 60 fps. This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. [...] >>> >>> I wonder if I'm chasing a ghost there... am I really the only one >>> seeing this? I can't get this index rebuilding to work regardless >>> if I try it with old or new recordings, if I mv away the original >>> index file that was created with a recording I always get totally >>> different index files rebuilt (checked with hexdump/cmp -l) that >>> cause playbacks (via xineliboutput) to look quite corrupted immediately >>> and make vdr-sxfe hang at eof too. >>> >>> This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, >>> FreeBSD 8.2/amd64, using these ports: >>> >>> http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar >>> >>> (originally noticed with recordings from arte hd on 19.2E, but also >>> reproduced with new short sd recordings, even from dvb-t.) >> >> I just made a recording from "arte HD" with VDR 1.7.17 and everything worked >> fine. >> It played correctly (on a TT-S2 6400 prototype), the current and total >> times displayed by the progress display were correct and I was able to >> place and move an editing mark with the picture getting updated just >> fine. > > So it also works when you stop vdr, mv the recording's index > file away and then let vdr regenerate it? Yes, it does. > Could this be an amd64/x86_64 issue? Maybe, I don't know. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
In article <4d849b3a.6060...@tvdr.de> you write: >On 17.03.2011 22:36, Juergen Lock wrote: >> In article <4d7caea2.9050...@tvdr.de> you write: >>> VDR developer version 1.7.17 is now available at >>> >>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 >>> >>> A 'diff' against the previous version is available at >>> >>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff >>> >>> >>> >>> WARNING: >>> >>> >>> This is a *developer* version. Even though *I* use it in my productive >>> environment. I strongly recommend that you only use it under controlled >>> conditions and for testing and debugging. >>> >>> >>> [...] >>> - Fixed detecting frames on channels that broadcast with 50 or 60 fps. >>> This avoids artifacts during fast forward/rewind when replaying recordings >>> from such >>> channels. To fix the index of existing recordings from such channels, just >>> delete the >>> 'index' file of the recording and VDR will generate a new one the next >>> time you play it. >>> You should also change the line "F 25" to "F 50" in the 'info' file of >>> that recording. >>> [...] >> >> I wonder if I'm chasing a ghost there... am I really the only one >> seeing this? I can't get this index rebuilding to work regardless >> if I try it with old or new recordings, if I mv away the original >> index file that was created with a recording I always get totally >> different index files rebuilt (checked with hexdump/cmp -l) that >> cause playbacks (via xineliboutput) to look quite corrupted immediately >> and make vdr-sxfe hang at eof too. >> >> This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, >> FreeBSD 8.2/amd64, using these ports: >> >> http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar >> >> (originally noticed with recordings from arte hd on 19.2E, but also >> reproduced with new short sd recordings, even from dvb-t.) > >I just made a recording from "arte HD" with VDR 1.7.17 and everything worked >fine. >It played correctly (on a TT-S2 6400 prototype), the current and total >times displayed by the progress display were correct and I was able to >place and move an editing mark with the picture getting updated just >fine. So it also works when you stop vdr, mv the recording's index file away and then let vdr regenerate it? Could this be an amd64/x86_64 issue? Thanx, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 17.03.2011 22:36, Juergen Lock wrote: > In article <4d7caea2.9050...@tvdr.de> you write: >> VDR developer version 1.7.17 is now available at >> >> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 >> >> A 'diff' against the previous version is available at >> >> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff >> >> >> >> WARNING: >> >> >> This is a *developer* version. Even though *I* use it in my productive >> environment. I strongly recommend that you only use it under controlled >> conditions and for testing and debugging. >> >> >> [...] >> - Fixed detecting frames on channels that broadcast with 50 or 60 fps. >> This avoids artifacts during fast forward/rewind when replaying recordings >> from such >> channels. To fix the index of existing recordings from such channels, just >> delete the >> 'index' file of the recording and VDR will generate a new one the next time >> you play it. >> You should also change the line "F 25" to "F 50" in the 'info' file of that >> recording. >> [...] > > I wonder if I'm chasing a ghost there... am I really the only one > seeing this? I can't get this index rebuilding to work regardless > if I try it with old or new recordings, if I mv away the original > index file that was created with a recording I always get totally > different index files rebuilt (checked with hexdump/cmp -l) that > cause playbacks (via xineliboutput) to look quite corrupted immediately > and make vdr-sxfe hang at eof too. > > This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, > FreeBSD 8.2/amd64, using these ports: > > http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar > > (originally noticed with recordings from arte hd on 19.2E, but also > reproduced with new short sd recordings, even from dvb-t.) I just made a recording from "arte HD" with VDR 1.7.17 and everything worked fine. It played correctly (on a TT-S2 6400 prototype), the current and total times displayed by the progress display were correct and I was able to place and move an editing mark with the picture getting updated just fine. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
In article <4d7caea2.9050...@tvdr.de> you write: >VDR developer version 1.7.17 is now available at > > ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 > >A 'diff' against the previous version is available at > > ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff > > > >WARNING: > > >This is a *developer* version. Even though *I* use it in my productive >environment. I strongly recommend that you only use it under controlled >conditions and for testing and debugging. > > >[...] >- Fixed detecting frames on channels that broadcast with 50 or 60 fps. > This avoids artifacts during fast forward/rewind when replaying recordings > from such > channels. To fix the index of existing recordings from such channels, just > delete the > 'index' file of the recording and VDR will generate a new one the next time > you play it. > You should also change the line "F 25" to "F 50" in the 'info' file of that > recording. >[...] I wonder if I'm chasing a ghost there... am I really the only one seeing this? I can't get this index rebuilding to work regardless if I try it with old or new recordings, if I mv away the original index file that was created with a recording I always get totally different index files rebuilt (checked with hexdump/cmp -l) that cause playbacks (via xineliboutput) to look quite corrupted immediately and make vdr-sxfe hang at eof too. This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, FreeBSD 8.2/amd64, using these ports: http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar (originally noticed with recordings from arte hd on 19.2E, but also reproduced with new short sd recordings, even from dvb-t.) ..and before I forget, Thanx for vdr! :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Hi,
Am 14.03.2011 09:54, schrieb Simon Baxter:
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter
wrote:
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting
these error
messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching
to MPEG1/2
mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating
in MPEG1/2
mode
Those aren't error messages, they're just information messages
from vdr-xine.
Sorry, forgot to mention - I'm getting severe video slipping. The
audio sounds OK, but the video skips every few seconds as per the
timestamps:
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Looks like you're missing a patch for vdr-xine-0.9.3 to make it
compatible with vdr-1.7.12. Because since that version, channels
with PPID != VPID are handled differently by VDR, hence causing
this issue in vdr-xine.
vdr-xine-0.9.4 will include that patch, but it will still take a
few days to get it ready.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../xine-0.9.3/xineDevice.c 2009-06-17 20:06:35.0 +0200
+++ xineDevice.c 2010-02-08 22:54:00.0 +0100
@@ -1539,7 +1546,13 @@ fclose(ff);
{
#if APIVERSNUM >= 10701
if (Length >= TS_SIZE)
- m_tsVideoPid = TsPid(Data);
+{
+#if APIVERSNUM >= 10712
+ m_tsVideoPid = PatPmtParser()->Vpid();
+#else
+ m_tsVideoPid = TsPid(Data);
+#endif
+}
#endif
return Length;
}
@@ -4119,6 +4132,8 @@ store_frame(jumboPESdata, todo, __LINE__
void cXineDevice::MakePrimaryDevice(bool On)
{
+cDevice::MakePrimaryDevice(On);
+
xfprintf(stderr, "-\n");
xfprintf(stderr, "MakePrimaryDevice: %d\n", On);
xfprintf(stderr, "=\n");
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter wrote: Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error messages. Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Those aren't error messages, they're just information messages from vdr-xine. Sorry, forgot to mention - I'm getting severe video slipping. The audio sounds OK, but the video skips every few seconds as per the timestamps: Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter wrote: > Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error > messages. > > Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 > mode > Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 > mode Those aren't error messages, they're just information messages from vdr-xine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error
messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:09:01 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:09:01 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:09:09 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:09:09 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:09:14 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:09:14 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:09:18 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:09:18 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
I see there were some few changes in remux.c - any thoughts?
The only patch I've implemented in both vdr-1.7.16 and vdr-1.7.17 is as
follows, to get around a problem decoding my dvb-c channels:
# diff device.c.orig device.c
1502,1513c1502,1513
< if (CamSlotNumber) {
TS_SCRAMBLING_TIMEOUT)
< DetachReceivers = true;
< }
TS_SCRAMBLING_TIME_OK) {
< DescramblingOk = true;
< startScrambleDetection = 0;
< }
<}
---
//SBB if (CamSlotNumber) {
// bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
// int t = time(NULL) - startScrambleDetection;
// if (Scrambled) {
// if (t > TS_SCRAMBLING_TIMEOUT)
// DetachReceivers = true;
// }
// else if (t > TS_SCRAMBLING_TIME_OK) {
// DescramblingOk = true;
// startScrambleDetection = 0;
// }
// }
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 13.03.2011 14:38, Matti Lehtimäki wrote: > On 2011-03-13 13:46, Klaus Schmidinger wrote: > >> - Changed the compiler optimization flag to -O3, which gives quite a >> performance >>boost in the AlphaBlend() function. > > I noticed that this change was not made to Make.config.template as it > should be since Make.config overrides CFLAGS and CXXFLAGS defined in > Makefile. Sorry, must have missed that one. Changed for 1.7.18. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 2011-03-13 13:46, Klaus Schmidinger wrote: - Changed the compiler optimization flag to -O3, which gives quite a performance boost in the AlphaBlend() function. I noticed that this change was not made to Make.config.template as it should be since Make.config overrides CFLAGS and CXXFLAGS defined in Makefile. -Matti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On 13.03.2011 14:11, Luca Olivetti wrote: > Al 13/03/11 12:46, En/na Klaus Schmidinger ha escrit: > >> This version introduces support for TrueColor OSD. >> Note, though, that output plugins need to be enhanced in order >> to support actual TrueColor display (if the device they control >> can handle TrueColor). > > And if it cannot, will it work without modifications? > What about plugins that just draw to an osd, will they work > without modifications? Everything should work without modifications. At least that's the plan ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Al 13/03/11 12:46, En/na Klaus Schmidinger ha escrit: > This version introduces support for TrueColor OSD. > Note, though, that output plugins need to be enhanced in order > to support actual TrueColor display (if the device they control > can handle TrueColor). And if it cannot, will it work without modifications? What about plugins that just draw to an osd, will they work without modifications? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.17
VDR developer version 1.7.17 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version introduces support for TrueColor OSD. Note, though, that output plugins need to be enhanced in order to support actual TrueColor display (if the device they control can handle TrueColor). Also, skins that want to make use of TrueColor may need to be adapted to the new interface using cPixmap. The changes since version 1.7.16: - Updated the Estonian OSD texts (thanks to Arthur Konovalov). - Fixed following symbolic links in RemoveFileOrDir() (cont'd) (thanks to Steffen Barszus). - Changed the description of cDevice::GetSTC() to make it mandatory for devices that can replay. - Removed the check for positive STC values from cDvbSubtitleConverter::Action(). - Added cString::operator=(const char *String) (suggested by Antti Seppälä). - Some spelling fixes (thanks to Ville Skyttä). - Passing package name and version to xgettext (thanks to Ville Skyttä). - Made 'dist' target dependent on up to date *.po (thanks to Ville Skyttä). - Added Language and fixed Language-Team header of *.po (thanks to Ville Skyttä). - Updated the Lithuanian OSD texts (thanks to Valdemaras Pipiras). - Fixed detecting frames on channels that broadcast with 50 or 60 fps. This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. - Added support for "registration descriptor" to 'libsi' and using it in pat.c (thanks to Rolf Ahrenberg). - Fixed unjustified log entries about changed channel pids (reported by Derek Kelly). - Added an include of VDR's 'Make.global' to libsi's Makefile (thanks to Rolf Ahrenberg). - Removed displaying the "contents" information from the "Classic VDR" and "ST:TNG Panels" skins, because it is often wrong and nothing but irritating. - Added typecasts to avoid gcc 4.5 warnings in switch statements on eKeys variables where additional 'k_...' flags are used. - Fixed inclusion of (thanks to Henning Heinold). - Changed "frame duration" to "frame rate" in vdr.5 (reported by Tobias Grimm). - Removing a cRemote from the Remotes list in case its initialization failed (thanks to Dominik Strasser). - Added LDFLAGS to the linker calls in the Makefiles (thanks to Joerg Bornkessel and Paul Menzel). - Now updating the 'frames per second' data in the list of recordings when a new recording is started that has a frame rate other than the default. - The include path to the freetype2 header files is now retrieved via a call to 'pkg-config --cflags freetype2' (suggested by Andreas Oberritter). - The OSD now has full TrueColor support. There can be several "pixmaps" that can be overlayed with alpha blending. All existing skins should work out of the box with the TrueColor OSD - the only exception being cOsd::GetBitmap(). Since the TrueColor OSD doesn't use bitmaps, this function will return a dummy bitmap, which may not be what the plugin expects. As long as this bitmap is only used for setting the palette, there is no problem. However, any other operations on this bitmap will have no effect. See the description of the cPixmap functions in osd.h for details about the new functionalities. The "ST:TNG Panels" skin has been enhanced to automatically use the TrueColor OSD if available. The "osddemo" plugin has been extended to show some of the possibilities of the TrueColor OSD if it is run on a system that actually provides TrueColor support. Thanks to Reinhard Nissl for some valuable input, help with debugging, and an implementation of the AlphaBlend() function. - Updated the Slovakian language texts (thanks to Milan Hrala). - Added Serbian language texts (thanks to Milan Cvijanovic). - Fixed reallocating memory in the "pictures" plugin (reported by Paul Menzel, with input from Oliver Endriss). - Fixed reallocating memory in cTsToPes::PutTs() (suggested by Oliver Endriss). - Now checking the result of all realloc() calls. - Fixed setting up the 'Recordings' menu in case there are several recordings with exactly the same name (reported by Marcus Hilbrich). - Setting the audio type of language descriptors to 0x00 in the PAT/PMT generator (thanks to Anssi Hannula). - Changed the compiler optimization flag to -O3, which gives quite a performance boost in the AlphaBlend() function. - While replaying, the editing marks are now updated every
