On Wed, 06 Jul 2005 05:33:03 +0000, C.Y.M wrote:
yes
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"
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]
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.
261d is the best release for me too.
Regards.
On Sat, Jul 30, 2005 at 09:41:34AM +0000, Stefan Huelswitt wrote:
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:
This is with AC3.
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:
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
On Fri, Jul 08, 2005 at 10:38:39AM +0200, Soeren Sonnenburg wrote:
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
On Thu, Aug 25, 2005 at 09:13:22PM -0700, C.Y.M wrote:
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:
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:
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
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
1.3.29)
?
? yaepg.c:444: error: (Each undeclared identifier is reported only once
for
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
Anssi Hannula wrote:
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:
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:
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
On Fri, Sep 02, 2005 at 03:42:50PM +0300, Anssi Hannula wrote:
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
On Fri, Sep 02, 2005 at 03:42:50PM +0300, Anssi Hannula wrote:
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:
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:
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