On Wed, 06 Jul 2005 05:33:03 +0000, C.Y.M wrote:
Suur Karu wrote:
Johannes Stezenbach wrote:
A summary of the changes is also available under the above link, for me the highlights are better error handling and smoother a/v sync.
Thanks, but one year shift happens in av7110 changes descriptions head. :)
By the way, do You know about black screen, no audio and probably vdr hang using Mplayer plugin with last (261e?) firmware? Is it solved now?
yes
There were about 4 or 5 uploaded versions of 0x261e before it was changed to 0x261f. The versions of 0x261e from 2005-06-16 and 2005-06-23 were both not working with the mplayer plugin because of a Mute/Unmute feature that was added to the firmware to allow mute during playback. This "Mute/Unmute" feature was then removed from 0x261e on the 2005-06-30 release still located on http://www.suse.de/~werner/test_av.tar.bz2 (hopefully 0x261f works too). :)
yeah but that one makes the mp3 plugin stutter (well now there is some 'tick' 'tick' in every soundtrack)
0x261d was the last really nicely working firmware for me...
Soeren
Regards, C.
This "Mute/Unmute"
feature was
then removed from 0x261e on the 2005-06-30 release still located on http://www.suse.de/~werner/test_av.tar.bz2 (hopefully 0x261f works too).
:)
yeah but that one makes the mp3 plugin stutter (well now there is some 'tick' 'tick' in every soundtrack)
And here the same with muggle, when mp3 audio files are replayed
0x261d was the last really nicely working firmware for me...
Soeren
For me too - with 0x261f I also get "unknown picture errors" when a recording is starting: I did not see these errors with 0x261d and latest cvs dvb driver
Regards,
Martin
On 08 Jul 2005 "Martin Binder (AON)" martin_binder@aon.at wrote:
[261f release]
yeah but that one makes the mp3 plugin stutter (well now there is some 'tick' 'tick' in every soundtrack)
And here the same with muggle, when mp3 audio files are replayed
Finaly I managed to install 261f. I cannot reproduce your problem with mp3 replay. The audio is fine. But I have still problems on DVD replay. There audio dropouts every seconds. This seems to be the same with all 261e and 261f.
0x261d was the last really nicely working firmware for me...
For me too - with 0x261f I also get "unknown picture errors" when a recording is starting: I did not see these errors with 0x261d and latest cvs dvb driver
261d is the best release for me too.
Regards.
On Sat, Jul 30, 2005 at 09:41:34AM +0000, Stefan Huelswitt wrote:
On 08 Jul 2005 "Martin Binder (AON)" martin_binder@aon.at wrote:
[261f release]
yeah but that one makes the mp3 plugin stutter (well now there is some 'tick' 'tick' in every soundtrack)
And here the same with muggle, when mp3 audio files are replayed
Finaly I managed to install 261f. I cannot reproduce your problem with mp3 replay. The audio is fine. But I have still problems on DVD replay. There audio dropouts every seconds. This seems to be the same with all 261e and 261f.
0x261d was the last really nicely working firmware for me...
For me too - with 0x261f I also get "unknown picture errors" when a recording is starting: I did not see these errors with 0x261d and latest cvs dvb driver
261d is the best release for me too.
Hmmm ... Question: Do you use PCM/Stereo with the DVD plugin or does this happen with AC3/DTS?
And what does happen if you are replaying a striped down VOB from a DVD? You can do this with the help of e.g. vob2vdr ffrom the tools directory of the bitstreamout plugin, renaming the result to 001.vdr and running genindex on this.
Werner
On 04 Aug 2005 "Dr. Werner Fink" werner@suse.de wrote:
On Sat, Jul 30, 2005 at 09:41:34AM +0000, Stefan Huelswitt wrote:
But I have still problems on DVD replay. There audio dropouts every seconds. This seems to be the same with all 261e and 261f.
0x261d was the last really nicely working firmware for me...
For me too - with 0x261f I also get "unknown picture errors" when a recording is starting: I did not see these errors with 0x261d and latest cvs dvb driver
261d is the best release for me too.
Hmmm ... Question: Do you use PCM/Stereo with the DVD plugin or does this happen with AC3/DTS?
This is with AC3.
And what does happen if you are replaying a striped down VOB from a DVD? You can do this with the help of e.g. vob2vdr ffrom the tools directory of the bitstreamout plugin, renaming the result to 001.vdr and running genindex on this.
I'll try and report later.
Regards.
On 04 Aug 2005 "Dr. Werner Fink" werner@suse.de wrote:
And what does happen if you are replaying a striped down VOB from a DVD?
Hmm, may sound like a stupid question:
How do I rip the contents of an encrypted DVD?
If the answer is DVD::Rip: this is not an option as the system is quite old and this would lead to a massive update session.
Regards.
On Thu, Aug 04, 2005 at 04:50:54PM +0000, Stefan Huelswitt wrote:
On 04 Aug 2005 "Dr. Werner Fink" werner@suse.de wrote:
And what does happen if you are replaying a striped down VOB from a DVD?
Hmm, may sound like a stupid question:
How do I rip the contents of an encrypted DVD?
If the answer is DVD::Rip: this is not an option as the system is quite old and this would lead to a massive update session.
Without update you may use an old trick. Simply open a new file with fopen() and write the resulting stream with fwrite() at the same place where PlayPes() in the dvd plugin is called. Don't to forget to remove the code after you've get the resulting stream.
Werner
Am Donnerstag 04 August 2005 18:50 schrieb Stefan Huelswitt:
On 04 Aug 2005 "Dr. Werner Fink" werner@suse.de wrote:
And what does happen if you are replaying a striped down VOB from a DVD?
Hmm, may sound like a stupid question:
How do I rip the contents of an encrypted DVD?
lxdvdrip is a command line tool which relieves you from typing long options for various commands. However, it still has some dependencies (dvdauthor, streamdvd).
Marcel
If the answer is DVD::Rip: this is not an option as the system is quite old and this would lead to a massive update session.
Regards.
On Fri, Jul 08, 2005 at 10:38:39AM +0200, Soeren Sonnenburg wrote:
On Wed, 06 Jul 2005 05:33:03 +0000, C.Y.M wrote:
There were about 4 or 5 uploaded versions of 0x261e before it was changed to 0x261f. The versions of 0x261e from 2005-06-16 and 2005-06-23 were both not working with the mplayer plugin because of a Mute/Unmute feature that was added to the firmware to allow mute during playback. This "Mute/Unmute" feature was then removed from 0x261e on the 2005-06-30 release still located on http://www.suse.de/~werner/test_av.tar.bz2 (hopefully 0x261f works too). :)
yeah but that one makes the mp3 plugin stutter (well now there is some 'tick' 'tick' in every soundtrack)
0x261d was the last really nicely working firmware for me...
You may also try out the test version of 0x2620 at
http://www.suse.de/~werner/test_av.tar.bz2
to see if the problems with mp3/muggle and the DVD plugin are solved.
Werner
Dr. Werner Fink wrote:
You may also try out the test version of 0x2620 at
http://www.suse.de/~werner/test_av.tar.bz2to see if the problems with mp3/muggle and the DVD plugin are solved.
Werner, can you tell us what is new in 0x2620?
Best Regards.
On Thu, Aug 25, 2005 at 09:13:22PM -0700, C.Y.M wrote:
Dr. Werner Fink wrote:
You may also try out the test version of 0x2620 at
http://www.suse.de/~werner/test_av.tar.bz2to see if the problems with mp3/muggle and the DVD plugin are solved.
Werner, can you tell us what is new in 0x2620?
From CVS
Small bugfixes and enhancments in AV sync of PCM Bypass (me). Fix of the Dpram timings and prefetch (Oliver). Fix in OSD error handling (Marco).
Werner
On Fri, 26 Aug 2005 09:29:38 +0000, Dr. Werner Fink wrote:
On Thu, Aug 25, 2005 at 09:13:22PM -0700, C.Y.M wrote:
Dr. Werner Fink wrote:
You may also try out the test version of 0x2620 at
http://www.suse.de/~werner/test_av.tar.bz2to see if the problems with mp3/muggle and the DVD plugin are solved.
Werner, can you tell us what is new in 0x2620?
From CVS
Small bugfixes and enhancments in AV sync of PCM Bypass (me). Fix of the Dpram timings and prefetch (Oliver). Fix in OSD error handling (Marco).
Werner
I was running this firmware now for several days, it seems to work more stable w.r.t. OSD problems, but the 'tick-tick' was still there when the mp3 plugin is used.
Soeren
On Wed, Aug 31, 2005 at 08:52:04PM +0200, Soeren Sonnenburg wrote:
On Fri, 26 Aug 2005 09:29:38 +0000, Dr. Werner Fink wrote:
On Thu, Aug 25, 2005 at 09:13:22PM -0700, C.Y.M wrote:
Dr. Werner Fink wrote:
You may also try out the test version of 0x2620 at
http://www.suse.de/~werner/test_av.tar.bz2to see if the problems with mp3/muggle and the DVD plugin are solved.
Werner, can you tell us what is new in 0x2620?
From CVS
Small bugfixes and enhancments in AV sync of PCM Bypass (me). Fix of the Dpram timings and prefetch (Oliver). Fix in OSD error handling (Marco).
WernerI was running this firmware now for several days, it seems to work more stable w.r.t. OSD problems, but the 'tick-tick' was still there when the mp3 plugin is used.
What does 'tick-tick' mean? Which VDR, mp3 and driver version do you use? What does you replay (PCM or DTS, with 44.1kHz or 48kHz)? Why does Stefan Huelswitt, the mp3 author, not hear those 'tick-tick'?
Hmmm ... many questions and currently no answer useful for debugging the problem.
Werner
Is anyone working on YAEPG as I get the following problems (Ok with 1.3.29) :-
yaepg.c: In constructor `cChanBox::cChanBox()': ? yaepg.c:444: error: `fontYaepg' undeclared (first use this function) ? ? yaepg.c:444: error: (Each undeclared identifier is reported only once for each? ? function it appears in.) ? ? yaepg.c: In constructor `cNoInfoEvent::cNoInfoEvent(long int, tChannelID)':? ? yaepg.c:667: error: no matching function for call to `cEvent::cEvent( ? ? tChannelID&, int)' ? ? /usr/local/src/VDR/include/vdr/epg.h:49: error: candidates are:? ? cEvent::cEvent(const cEvent&)? ? /usr/local/src/VDR/include/vdr/epg.h:66: error:? ? cEvent::cEvent(short unsigned int) ? ? yaepg.c: In member function `virtual void cYaepg::Show()':? ? yaepg.c:1304: error: 'class cOsd' has no member named 'vidWin' ? ? yaepg.c:1305: error: 'class cOsd' has no member named 'vidWin'? ? yaepg.c:1306: error: 'class cOsd' has no member named 'vidWin'? ? yaepg.c:1307: error: 'class cOsd' has no member named 'vidWin'? ? yaepg.c:1308: error: 'class cOsd' has no member named 'vidWin'? ? /usr/local/src/VDR/include/vdr/device.h: In member function `void? ? cYaepg::SwitchToCurrentChannel()':? ? /usr/local/src/VDR/include/vdr/device.h:226: error: `eSetChannelResult? ? cDevice::SetChannel(const cChannel*, bool)' is private? ? yaepg.c:1384: error: within this context? ? yaepg.c: In member function `virtual eOSState cYaepg::ProcessKey(eKeys)':? ? yaepg.c:1609: error: `time_ms' undeclared (first use this function)? ? make[1]: *** [yaepg.o] Error 1? ? make: *** [plugins] Error 2
On Thu, 2005-09-01 at 10:55 +0100, Mike Parker wrote:
Is anyone working on YAEPG as I get the following problems (Ok with 1.3.29) :-
yaepg.c: In constructor `cChanBox::cChanBox()': ? yaepg.c:444: error: `fontYaepg' undeclared (first use this function) ? ? yaepg.c:444: error: (Each undeclared identifier is reported only once for each?
{snippage}
Did you forget to patch vdr with the yaepg patch? It built fine for me with vdr-1.3.31 (after patching vdr!).
Cheers,
Laz
Laurence Abbott wrote:
On Thu, 2005-09-01 at 10:55 +0100, Mike Parker wrote:
Is anyone working on YAEPG as I get the following problems (Ok with 1.3.29) :-
yaepg.c: In constructor `cChanBox::cChanBox()': ? yaepg.c:444: error: `fontYaepg' undeclared (first use this function) ? ? yaepg.c:444: error: (Each undeclared identifier is reported only once for each?
{snippage}
Did you forget to patch vdr with the yaepg patch? It built fine for me with vdr-1.3.31 (after patching vdr!).
Cheers,
Laz
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Yes, that is what it sounds like is wrong, you forgot to apply the Core-Yaepg patch to your core VDR. Do that and I bet you are fixed up.
Chad
Thanks Chad & Laurence
As mentioned - this works ok with 1.3.29 - just upgraded to 1.3.31. I am using the vdr install script.
Mike
----- Original Message ----- From: "Chad Flynt" hoochster@sofnet.com To: "Klaus Schmidinger's VDR" vdr@linuxtv.org Sent: Thursday, September 01, 2005 4:32 PM Subject: Re: [vdr] YAEPG problems with 1.3.31
Laurence Abbott wrote:
On Thu, 2005-09-01 at 10:55 +0100, Mike Parker wrote:
Is anyone working on YAEPG as I get the following problems (Ok with
1.3.29)
:-
yaepg.c: In constructor `cChanBox::cChanBox()': ? yaepg.c:444: error: `fontYaepg' undeclared (first use this function)
?
? yaepg.c:444: error: (Each undeclared identifier is reported only once
for
each?
{snippage}
Did you forget to patch vdr with the yaepg patch? It built fine for me with vdr-1.3.31 (after patching vdr!).
Cheers,
Laz
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Yes, that is what it sounds like is wrong, you forgot to apply the Core-Yaepg patch to your core VDR. Do that and I bet you are fixed up.
Chad
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.17/85 - Release Date: 30/08/05
On Thu, 1 Sep 2005, Dr. Werner Fink wrote:
Hmmm ... many questions and currently no answer useful for debugging the problem.
Well, you'll need a few more questions ;) I'm having problems with both 261f and 2620 firmwares. They generate visible (not audible) hickups on my 4Mb-modded-FF-DVB-S-rev1.6 card about every five minutes, but the old 261d is working like a charm. The hickups look like a few video frames were skipped, but only on video - the audio seems to be fine during these anomalies. The problem isn't related to any partical channel, but the hickups are noticeable on every DVB-T channels I'm watching on regular basis.
Yes, my FF card is mainly used as a tv out, so these hickups occur while vdr (1.3.31) is in transfer mode (Airstar2). My DVB drivers are from 12.07.2005.
BR, -- rofa
Rolf Ahrenberg wrote:
On Thu, 1 Sep 2005, Dr. Werner Fink wrote:
Hmmm ... many questions and currently no answer useful for debugging the problem.
Well, you'll need a few more questions ;) I'm having problems with both 261f and 2620 firmwares. They generate visible (not audible) hickups on my 4Mb-modded-FF-DVB-S-rev1.6 card about every five minutes, but the old 261d is working like a charm. The hickups look like a few video frames were skipped, but only on video - the audio seems to be fine during these anomalies. The problem isn't related to any partical channel, but the hickups are noticeable on every DVB-T channels I'm watching on regular basis.
Yes, my FF card is mainly used as a tv out, so these hickups occur while vdr (1.3.31) is in transfer mode (Airstar2). My DVB drivers are from 12.07.2005.
I have the same thing here with non-modded card.
Anssi Hannula wrote:
Rolf Ahrenberg wrote:
On Thu, 1 Sep 2005, Dr. Werner Fink wrote:
Hmmm ... many questions and currently no answer useful for debugging the problem.
Well, you'll need a few more questions ;) I'm having problems with both 261f and 2620 firmwares. They generate visible (not audible) hickups on my 4Mb-modded-FF-DVB-S-rev1.6 card about every five minutes, but the old 261d is working like a charm. The hickups look like a few video frames were skipped, but only on video - the audio seems to be fine during these anomalies. The problem isn't related to any partical channel, but the hickups are noticeable on every DVB-T channels I'm watching on regular basis.
Yes, my FF card is mainly used as a tv out, so these hickups occur while vdr (1.3.31) is in transfer mode (Airstar2). My DVB drivers are from 12.07.2005.
I have the same thing here with non-modded card.
Are you getting any cRepacker related log messages when that happens?
Please test whether this also occurs if you disable the cRepackers in VDR/remux.c by commenting out the lines
#define TEST_cVideoRepacker #define TEST_cAudioRepacker
Klaus
On Thu, 1 Sep 2005, Klaus Schmidinger wrote:
Are you getting any cRepacker related log messages when that happens?
No. The log is clean.
Please test whether this also occurs if you disable the cRepackers in VDR/remux.c by commenting out the lines
Well, haven't tried that, but I doubt it won't have any effect. As I said with the 261d firmware the situation is fine with both video and audio repackers enabled (or atleast much more rare phenomen).
I said in my earlier post that there are no noticeable audio hickups, but on the other hand there were quite many times when vdr did lose the lip sync that were cured by changing the channel back and forth or by stoping the playback for awhile. This could also be my imagination, but I'm ready to blame the new firmwares ;)
-- rofa
Rolf Ahrenberg wrote:
I said in my earlier post that there are no noticeable audio hickups, but on the other hand there were quite many times when vdr did lose the lip sync that were cured by changing the channel back and forth or by stoping the playback for awhile. This could also be my imagination, but I'm ready to blame the new firmwares ;)
Now that you mention it, I might have noticed this, too. IIRC the audio started to fall behind pretty fast. I didn't try switching channel, though. I switched the firmware back from 261e to 261d, and this hasn't happened again.
Of course I _should_ have made a bugreport :I
I'm probably going to update my VDR this friday, and I guess I'll also try the newest firmware, and see if the problems appear again.
On Fri, Sep 02, 2005 at 12:43:51AM +0300, Anssi Hannula wrote:
Anssi Hannula wrote:
I switched the firmware back from 261e to 261d, and this hasn't happened again.
Sorry, I meant 261f -> 261d.
OK, I'd like to ask if this problem happen with AC3 or with Mpeg Audio channels or with both?
For last one I've add simple approach to guess the current delay of the HW audio buffer of the DVB card to be able to get a more precise value if or if not the audio is in synch with the picture.
Werner
Dr. Werner Fink wrote:
On Fri, Sep 02, 2005 at 12:43:51AM +0300, Anssi Hannula wrote:
Anssi Hannula wrote:
I switched the firmware back from 261e to 261d, and this hasn't happened again.
Sorry, I meant 261f -> 261d.
OK, I'd like to ask if this problem happen with AC3 or with Mpeg Audio channels or with both?
MPEG.
For last one I've add simple approach to guess the current delay of the HW audio buffer of the DVB card to be able to get a more precise value if or if not the audio is in synch with the picture.
I'll report this weekend if there are problems with the newest firmware, which I'm going to install today.
On Fri, Sep 02, 2005 at 03:42:50PM +0300, Anssi Hannula wrote:
Dr. Werner Fink wrote:
For last one I've add simple approach to guess the current delay of the HW audio buffer of the DVB card to be able to get a more precise value if or if not the audio is in synch with the picture.
I'll report this weekend if there are problems with the newest firmware, which I'm going to install today.
This approach is included since 0x261e and therefore also in 0x261f and 0x2620. I'll think about a new approach.
Werner
On Fri, 2 Sep 2005, Dr. Werner Fink wrote:
OK, I'd like to ask if this problem happen with AC3 or with Mpeg Audio channels or with both?
Sorry, no AC3 channels here so all my observations are from pure mpeg ones. If you want some more detailed infos or some kind of debugging logs, please, you can contact me directly. It just makes me wonder why nobody else than Anssi hasn't noticed those hickups - is there something fishy in finnish mpeg streams or is Anssi's setup identical to mine?
EPIA MII + DVB-S rev1.6 + Airstar2 + Cinergy T2
BR, -- rofa
Rolf Ahrenberg wrote:
It just makes me wonder why nobody else than Anssi hasn't noticed those hickups - is there something fishy in finnish mpeg streams or is Anssi's setup identical to mine?
EPIA MII + DVB-S rev1.6 + Airstar2 + Cinergy T2
I have Abit NF7-S2 + DVB-S rev1.5 + 2x Airstar2 + KWORLD DVB-T.
On Fri, Sep 02, 2005 at 03:42:50PM +0300, Anssi Hannula wrote:
Dr. Werner Fink wrote:
On Fri, Sep 02, 2005 at 12:43:51AM +0300, Anssi Hannula wrote:
Anssi Hannula wrote:
I switched the firmware back from 261e to 261d, and this hasn't happened again.
Sorry, I meant 261f -> 261d.
OK, I'd like to ask if this problem happen with AC3 or with Mpeg Audio channels or with both?
MPEG.
Do you have an example recording, something about 20 - 30 seconds will be enough.
I'll need that for comparision with the records I have from german, american and austrian TV stations. Please with any VDR version _before_ 1.3.31 because Reinhard is hunting a problem with the cAudioRepacker class of that version.
Werner
On Fri, 2005-09-02 at 23:57 +0300, Anssi Hannula wrote:
Rolf Ahrenberg wrote:
It just makes me wonder why nobody else than Anssi hasn't noticed those hickups - is there something fishy in finnish mpeg streams or is Anssi's setup identical to mine?
EPIA MII + DVB-S rev1.6 + Airstar2 + Cinergy T2
I have Abit NF7-S2 + DVB-S rev1.5 + 2x Airstar2 + KWORLD DVB-T.
I have the same symptoms, but it's only noticeable when there is recording at background. I only have one dvb card so the channel that I'm watching has jerky picture (every now and then, picture hangs for a little period of time and after that gets like fast forward), audio on the other hand plays fine without no hickups.
When switching back from 261f or 2620 (tested them both) to 261d, video and audio stream plays fine.
Asus Pundit-S + 2,4GHz Pentium 4 + TT DVB-C 2.1
Dr. Werner Fink wrote:
On Fri, Sep 02, 2005 at 03:42:50PM +0300, Anssi Hannula wrote:
Dr. Werner Fink wrote:
On Fri, Sep 02, 2005 at 12:43:51AM +0300, Anssi Hannula wrote:
Anssi Hannula wrote:
I switched the firmware back from 261e to 261d, and this hasn't happened again.
Sorry, I meant 261f -> 261d.
OK, I'd like to ask if this problem happen with AC3 or with Mpeg Audio channels or with both?
MPEG.
Do you have an example recording, something about 20 - 30 seconds will be enough.
I'll need that for comparision with the records I have from german, american and austrian TV stations. Please with any VDR version _before_ 1.3.31 because Reinhard is hunting a problem with the cAudioRepacker class of that version.
Today with 1.3.31 & 2620 I confirmed the frameskipping problem is still there. There was also some hickups in the audio for few minutes, but I don't know if that's related to the firmware. Neither of these problems appear when I replay a recording made of the problematic stream.
Here's about 30sec long clip: (Recorded by some old version 3 months ago, cutted by 1.3.31, does that make a difference?) http://anssi.hopto.org/sample.vdr
Btw, I also had to lower the bitrate of mplayer-plugin's MPEG1 stream a few Mbps, because the new firmware couldn't keep up with the stream.
-
Anssi Hannula -
C.Y.M -
Chad Flynt -
Dr. Werner Fink -
Klaus Schmidinger -
Laurence Abbott -
Marcel Wiesweg -
Martin Binder (AON) -
Mike Parker -
Mikko Salo -
Rolf Ahrenberg -
s.huelswitt＠gmx.de -
Soeren Sonnenburg