[gentoo-user] Kmplayer, video and audio not syncing.

[gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Hi,

I'm still using KDE 3.5 for this but this is annoying at times.  I'm
looking for a way to adjust the audio/video so that they sync up.  Mine
seems to be about 1.5 to 2 seconds out of adjustment here.  I googled
and found that the + and - keys should adjust this but I can't tell that
it is working here.  Is there some other way to adjust this setting? 
I'm using kmplayer with mplayer for the backend.

INFO:

> root@smoker / # emerge -pv kmplayer mplayer
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies ... done!
> [ebuild   R   ] media-video/mplayer-1.0_rc2_p20090731  USE="3dnow X
> aac alsa ass cddb cdio dirac dv dvd dvdnav enca encode esd faac faad
> gif iconv ipv6 jpeg live mad mmx mng mp2 mp3 network opengl osdmenu
> png quicktime rar real rtc schroedinger sdl shm speex sse tremor
> truetype unicode vorbis win32codecs x264 xscreensaver xv xvid
> -3dnowext -a52 -aalib (-altivec) -bidi -bindist -bl -cdparanoia
> -cpudetection -custom-cflags -custom-cpuopts -debug -dga -directfb
> -doc -dts -dvb -dxr3 -fbcon -ftp -ggi -gmplayer -jack -joystick
> -ladspa -libcaca -lirc -lzo -md5sum -mmxext -nas -openal -oss -pnm
> -pulseaudio -pvr -radio -samba -sse2 -ssse3 -svga -teletext -tga
> -theora -v4l -v4l2 -vdpau -vidix -xanim -xinerama -xvmc -zoran"
> VIDEO_CARDS="nvidia -mga -s3virge -tdfx -vesa" 0 kB
> [ebuild   R   ] media-video/kmplayer-0.11.1b  USE="cairo (-aqua)
> -debug -doc -expat -npp" LINGUAS="-cs -da -de -el -en_GB -es -et -fr
> -ga -gl -it -ja -km -ku -lt -lv -mai -nb -nds -nl -nn -pl -pt -pt_BR
> -ro -ru -sk -sv -tr -uk" 0 kB
>
> Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
> root@smoker / #

Ideas?

Dale

:-)  :-)

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Alan McKinnon]

On Saturday 24 October 2009 22:16:03 Dale wrote:
> Hi,
> 
> I'm still using KDE 3.5 for this but this is annoying at times.  I'm
> looking for a way to adjust the audio/video so that they sync up.  Mine
> seems to be about 1.5 to 2 seconds out of adjustment here.  I googled
> and found that the + and - keys should adjust this but I can't tell that
> it is working here.  Is there some other way to adjust this setting?
> I'm using kmplayer with mplayer for the backend.

Are you sure the input file isn't broken? Does it happen with many files? What 
type of files?

2 seconds is a huge lag, much too big to explain as a mere bug, so I'd be 
looking for other data to correlate first.



> 
> INFO:
> > root@smoker / # emerge -pv kmplayer mplayer
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies ... done!
> > [ebuild   R   ] media-video/mplayer-1.0_rc2_p20090731  USE="3dnow X
> > aac alsa ass cddb cdio dirac dv dvd dvdnav enca encode esd faac faad
> > gif iconv ipv6 jpeg live mad mmx mng mp2 mp3 network opengl osdmenu
> > png quicktime rar real rtc schroedinger sdl shm speex sse tremor
> > truetype unicode vorbis win32codecs x264 xscreensaver xv xvid
> > -3dnowext -a52 -aalib (-altivec) -bidi -bindist -bl -cdparanoia
> > -cpudetection -custom-cflags -custom-cpuopts -debug -dga -directfb
> > -doc -dts -dvb -dxr3 -fbcon -ftp -ggi -gmplayer -jack -joystick
> > -ladspa -libcaca -lirc -lzo -md5sum -mmxext -nas -openal -oss -pnm
> > -pulseaudio -pvr -radio -samba -sse2 -ssse3 -svga -teletext -tga
> > -theora -v4l -v4l2 -vdpau -vidix -xanim -xinerama -xvmc -zoran"
> > VIDEO_CARDS="nvidia -mga -s3virge -tdfx -vesa" 0 kB
> > [ebuild   R   ] media-video/kmplayer-0.11.1b  USE="cairo (-aqua)
> > -debug -doc -expat -npp" LINGUAS="-cs -da -de -el -en_GB -es -et -fr
> > -ga -gl -it -ja -km -ku -lt -lv -mai -nb -nds -nl -nn -pl -pt -pt_BR
> > -ro -ru -sk -sv -tr -uk" 0 kB
> >
> > Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
> > root@smoker / #
> 
> Ideas?
> 
> Dale
> 
> :-)  :-)
> 

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Alan McKinnon wrote:
> On Saturday 24 October 2009 22:16:03 Dale wrote:
>   
>> Hi,
>>
>> I'm still using KDE 3.5 for this but this is annoying at times.  I'm
>> looking for a way to adjust the audio/video so that they sync up.  Mine
>> seems to be about 1.5 to 2 seconds out of adjustment here.  I googled
>> and found that the + and - keys should adjust this but I can't tell that
>> it is working here.  Is there some other way to adjust this setting?
>> I'm using kmplayer with mplayer for the backend.
>>     
>
> Are you sure the input file isn't broken? Does it happen with many files? What 
> type of files?
>
> 2 seconds is a huge lag, much too big to explain as a mere bug, so I'd be 
> looking for other data to correlate first.
>
>
>   

Well, it does vary by a bit.  Some are not quite so far off.  I did find
this little tidbit of info in 'console' under view.  This is interesting:

MPlayer SVN-r29463-4.4.1 (C) 2000-2009 MPlayer Team
Terminal type `unknown' is not defined.

libavformat file format detected.
ID_VIDEO_ID=0
[lavf] Video stream found, -vid 0
ID_AUDIO_ID=1
[lavf] Audio stream found, -aid 1
VIDEO:  [H264]  480x360  0bpp  29.917 fps  550.2 kbps (67.2 kbyte/s)
ID_FILENAME=/data/Movies/Movies/Clue Club 03 The Real Gone Gondola Pt 1.flv
ID_DEMUXER=lavfpref
ID_VIDEO_FORMAT=H264
ID_VIDEO_BITRATE=550208
ID_VIDEO_FPS=29.917
ID_AUDIO_FORMAT=255
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=44100
ID_AUDIO_NCH=2
ID_SEEKABLE=1
ID_CHAPTERS=0
[gl] using extended formats. Use -vo gl:nomanyfmts if playback fails.
Opening video filter: [pp=de]
Opening video filter: [scale]
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
ID_VIDEO_CODEC=ffh264
==========================================================================
Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
ID_AUDIO_BITRATE=128000
ID_AUDIO_RATE=44100
ID_AUDIO_NCH=2
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
FAAD: compressed input bitrate missing, assuming 128kbit/s!
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
ID_AUDIO_CODEC=faad
Starting playback...
VDec: vo config request - 480 x 360 (preferred colorspace: Planar YV12)
[PP] Using external postprocessing filter, max q = 6.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
[swscaler @ 0x8939540]using unscaled yuv420p -> rgb32 special converter
VO: [gl] 480x360 => 480x360 BGRA
X11 error: BadMatch (invalid parameter attributes)


           ************************************************
           **** Your system is too SLOW to play this!  ****
           ************************************************

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
  - Try -ao sdl or use the OSS emulation of ALSA.
  - Experiment with different values for -autosync, 30 is a good start.
- Slow video output
  - Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
  - Don't try to play a big DVD/DivX on a slow CPU! Try some of the
lavdopts,
    e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
  - Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
  - Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
  - Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.


So, my AMD 2500+ with 2GBs of ram is to slow?  I know this is a older
rig but surely it ain't that slow.  o_O

I also realized something else that may contribute to this a little.  I
started a emerge last night and thought it would be through by now. 
It's still running.  It's compiling OOo and some KDE stuff.  Could that
slow things down a bit?  Everything else seems to be responding fine.  I
have portage set to a lower nice level than my desktop.  I even have
ionice set. 

Ideas?

Dale

:-)  :-) 

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Alan McKinnon]

On Saturday 24 October 2009 22:36:59 Dale wrote:
> Alan McKinnon wrote:
> > On Saturday 24 October 2009 22:16:03 Dale wrote:
> >> Hi,
> >>
> >> I'm still using KDE 3.5 for this but this is annoying at times.  I'm
> >> looking for a way to adjust the audio/video so that they sync up.  Mine
> >> seems to be about 1.5 to 2 seconds out of adjustment here.  I googled
> >> and found that the + and - keys should adjust this but I can't tell that
> >> it is working here.  Is there some other way to adjust this setting?
> >> I'm using kmplayer with mplayer for the backend.
> >
> > Are you sure the input file isn't broken? Does it happen with many files?
> > What type of files?
> >
> > 2 seconds is a huge lag, much too big to explain as a mere bug, so I'd be
> > looking for other data to correlate first.
> 
> Well, it does vary by a bit.  Some are not quite so far off.  I did find
> this little tidbit of info in 'console' under view.  This is interesting:
> 
> MPlayer SVN-r29463-4.4.1 (C) 2000-2009 MPlayer Team
> Terminal type `unknown' is not defined.
> 
> libavformat file format detected.
> ID_VIDEO_ID=0
> [lavf] Video stream found, -vid 0
> ID_AUDIO_ID=1
> [lavf] Audio stream found, -aid 1
> VIDEO:  [H264]  480x360  0bpp  29.917 fps  550.2 kbps (67.2 kbyte/s)
> ID_FILENAME=/data/Movies/Movies/Clue Club 03 The Real Gone Gondola Pt 1.flv
> ID_DEMUXER=lavfpref
> ID_VIDEO_FORMAT=H264
> ID_VIDEO_BITRATE=550208
> ID_VIDEO_FPS=29.917
> ID_AUDIO_FORMAT=255
> ID_AUDIO_BITRATE=0
> ID_AUDIO_RATE=44100
> ID_AUDIO_NCH=2
> ID_SEEKABLE=1
> ID_CHAPTERS=0
> [gl] using extended formats. Use -vo gl:nomanyfmts if playback fails.
> Opening video filter: [pp=de]
> Opening video filter: [scale]
> ==========================================================================
> Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
> ==========================================================================
> ID_VIDEO_CODEC=ffh264
> ==========================================================================
> Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
> AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
> ID_AUDIO_BITRATE=128000
> ID_AUDIO_RATE=44100
> ID_AUDIO_NCH=2
> Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio))
> ==========================================================================
> FAAD: compressed input bitrate missing, assuming 128kbit/s!
> AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
> ID_AUDIO_CODEC=faad
> Starting playback...
> VDec: vo config request - 480 x 360 (preferred colorspace: Planar YV12)
> [PP] Using external postprocessing filter, max q = 6.
> VDec: using Planar YV12 as output csp (no 0)
> Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
> [swscaler @ 0x8939540]using unscaled yuv420p -> rgb32 special converter
> VO: [gl] 480x360 => 480x360 BGRA
> X11 error: BadMatch (invalid parameter attributes)
> 
> 
>            ************************************************
>            **** Your system is too SLOW to play this!  ****
>            ************************************************
> 
> Possible reasons, problems, workarounds:
> - Most common: broken/buggy _audio_ driver
>   - Try -ao sdl or use the OSS emulation of ALSA.
>   - Experiment with different values for -autosync, 30 is a good start.
> - Slow video output
>   - Try a different -vo driver (-vo help for a list) or try -framedrop!
> - Slow CPU
>   - Don't try to play a big DVD/DivX on a slow CPU! Try some of the
> lavdopts,
>     e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
> - Broken file
>   - Try various combinations of -nobps -ni -forceidx -mc 0.
> - Slow media (NFS/SMB mounts, DVD, VCD etc)
>   - Try -cache 8192.
> - Are you using -cache to play a non-interleaved AVI file?
>   - Try -nocache.
> Read DOCS/HTML/en/video.html for tuning/speedup tips.
> If none of this helps you, read DOCS/HTML/en/bugreports.html.
> 
> 
> So, my AMD 2500+ with 2GBs of ram is to slow?  I know this is a older
> rig but surely it ain't that slow.  o_O
> 
> I also realized something else that may contribute to this a little.  I
> started a emerge last night and thought it would be through by now.
> It's still running.  It's compiling OOo and some KDE stuff.  Could that
> slow things down a bit?  Everything else seems to be responding fine.  I
> have portage set to a lower nice level than my desktop.  I even have
> ionice set.
> 
> Ideas?

I haven't snipped - the output might be useful later in the thread.

First, the "slow system" message always means something, but it's a bit 
generic. It means that mplayer can't process the audio fast enough and like 
the message says is often buggy driver or wrong configs. Try the suggestions 
listed.

An OOo compile in the background will indeed kill interactive processes. I 
find that even on this DualCore2 2.6 notebook with 4G of RAM, building OOo 
sends the load through the roof, especially when it starts printing progress 
lines with lots of dots. It's IO blocking on something and the entire machine 
just sits there doing nothing whatsoever except sit in a tight loop waiting 
for soemthing to happen in the build.

Try again once emerge OOo has completed. emerge KDE should not affect things 
anywhere near the same amount.



-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Alan McKinnon wrote:
>
> I haven't snipped - the output might be useful later in the thread.
>
> First, the "slow system" message always means something, but it's a bit 
> generic. It means that mplayer can't process the audio fast enough and like 
> the message says is often buggy driver or wrong configs. Try the suggestions 
> listed.
>
> An OOo compile in the background will indeed kill interactive processes. I 
> find that even on this DualCore2 2.6 notebook with 4G of RAM, building OOo 
> sends the load through the roof, especially when it starts printing progress 
> lines with lots of dots. It's IO blocking on something and the entire machine 
> just sits there doing nothing whatsoever except sit in a tight loop waiting 
> for soemthing to happen in the build.
>
> Try again once emerge OOo has completed. emerge KDE should not affect things 
> anywhere near the same amount.
>
>
>
>   

I'm a snipping.  LOL  I haven't ignored this reply, I been testing some
things.  It appears that some file types are worse than others.  .mp4
for example seems to be worse than a .flv.  I'm still trying to make
some sense out of this so I can report back something that makes sense. 
Trust me, that can be a challenge for me sometimes.  ;-) 

Back when something falls into place.  Oh, waiting until OOo was done
compiling did help a LOT.  It's still a little bit off tho.

Dale

:-)  :-)

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Jesús Guerrero]

On Fri, 30 Oct 2009 06:17:51 -0500, Dale <rdalek1967@gmail.com> wrote:
> Alan McKinnon wrote:
>>
>> I haven't snipped - the output might be useful later in the thread.
>>
>> First, the "slow system" message always means something, but it's a bit

>> generic. It means that mplayer can't process the audio fast enough and
>> like
>> the message says is often buggy driver or wrong configs. Try the
>> suggestions
>> listed.
>>
>> An OOo compile in the background will indeed kill interactive
processes.
>> I
>> find that even on this DualCore2 2.6 notebook with 4G of RAM, building
>> OOo
>> sends the load through the roof, especially when it starts printing
>> progress
>> lines with lots of dots. It's IO blocking on something and the entire
>> machine
>> just sits there doing nothing whatsoever except sit in a tight loop
>> waiting
>> for soemthing to happen in the build.
>>
>> Try again once emerge OOo has completed. emerge KDE should not affect
>> things
>> anywhere near the same amount.
>>
>>
>>
>>   
> 
> I'm a snipping.  LOL  I haven't ignored this reply, I been testing some
> things.  It appears that some file types are worse than others.  .mp4
> for example seems to be worse than a .flv.  I'm still trying to make
> some sense out of this so I can report back something that makes sense. 
> Trust me, that can be a challenge for me sometimes.  ;-) 

kmplayer can get in the middle, can you -please- test regular mplayer from
command line?

I've had a similar issue a couple of weeks ago, and we were able to track
it down on the mplayer mailing lists. If it's the same bug, I was able to
consistently reproduce it in streams with ac3 (5.1) audio (stereo worked
fine), and only when using ALSA. So, check that and see if you can see a
pattern there. If you see that same pattern, then it might be the same bug,
it's been fixed in the development branch, and the following ebuilds should
work fine:

1.0_rc4_p20091026, 1.0_rc4_p20091026-r1, 9999

If not, then it's probably something else. But try with mplayer alone when
debugging, since kmplayer just adds another level to worry about. For your
reference, here's the bug I opened, there you can also find links to the
relevant mails in the mplayer ML.

http://bugs.gentoo.org/show_bug.cgi?id=286020

-- 
Jesús Guerrero

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Jesús Guerrero wrote:
>
> kmplayer can get in the middle, can you -please- test regular mplayer from
> command line?
>
> I've had a similar issue a couple of weeks ago, and we were able to track
> it down on the mplayer mailing lists. If it's the same bug, I was able to
> consistently reproduce it in streams with ac3 (5.1) audio (stereo worked
> fine), and only when using ALSA. So, check that and see if you can see a
> pattern there. If you see that same pattern, then it might be the same bug,
> it's been fixed in the development branch, and the following ebuilds should
> work fine:
>
> 1.0_rc4_p20091026, 1.0_rc4_p20091026-r1, 9999
>
> If not, then it's probably something else. But try with mplayer alone when
> debugging, since kmplayer just adds another level to worry about. For your
> reference, here's the bug I opened, there you can also find links to the
> relevant mails in the mplayer ML.
>
> http://bugs.gentoo.org/show_bug.cgi?id=286020
>
>   

I can give it a shot at least.  Do I just run mplayer path/to/file or do
I need to add some options so that it will provide more info?

I hate windoze but I like desktop GUI's.  LOL

Dale

:-)  :-) 

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Alan McKinnon]

On Saturday 31 October 2009 05:34:57 Dale wrote:
> Jesús Guerrero wrote:
> > kmplayer can get in the middle, can you -please- test regular mplayer
> > from command line?
> >
> > I've had a similar issue a couple of weeks ago, and we were able to track
> > it down on the mplayer mailing lists. If it's the same bug, I was able to
> > consistently reproduce it in streams with ac3 (5.1) audio (stereo worked
> > fine), and only when using ALSA. So, check that and see if you can see a
> > pattern there. If you see that same pattern, then it might be the same
> > bug, it's been fixed in the development branch, and the following ebuilds
> > should work fine:
> >
> > 1.0_rc4_p20091026, 1.0_rc4_p20091026-r1, 9999
> >
> > If not, then it's probably something else. But try with mplayer alone
> > when debugging, since kmplayer just adds another level to worry about.
> > For your reference, here's the bug I opened, there you can also find
> > links to the relevant mails in the mplayer ML.
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=286020
> 
> I can give it a shot at least.  Do I just run mplayer path/to/file or do
> I need to add some options so that it will provide more info?

If you run mplayer <file> it will try to autodetect what to do. Or you can 
look at the kmpayer config and find the corresponding options in mplayer's man 
page and use those to see if it makes a difference.

Beware the mplayer man page - it's huge, complex and a horrendous read. That's 
unavoidable - happens with any complex software that covers 100s of possible 
combinations.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Alan McKinnon wrote:
> On Saturday 31 October 2009 05:34:57 Dale wrote:
>   
>> Jesús Guerrero wrote:
>>     
>>> kmplayer can get in the middle, can you -please- test regular mplayer
>>> from command line?
>>>
>>> I've had a similar issue a couple of weeks ago, and we were able to track
>>> it down on the mplayer mailing lists. If it's the same bug, I was able to
>>> consistently reproduce it in streams with ac3 (5.1) audio (stereo worked
>>> fine), and only when using ALSA. So, check that and see if you can see a
>>> pattern there. If you see that same pattern, then it might be the same
>>> bug, it's been fixed in the development branch, and the following ebuilds
>>> should work fine:
>>>
>>> 1.0_rc4_p20091026, 1.0_rc4_p20091026-r1, 9999
>>>
>>> If not, then it's probably something else. But try with mplayer alone
>>> when debugging, since kmplayer just adds another level to worry about.
>>> For your reference, here's the bug I opened, there you can also find
>>> links to the relevant mails in the mplayer ML.
>>>
>>> http://bugs.gentoo.org/show_bug.cgi?id=286020
>>>       
>> I can give it a shot at least.  Do I just run mplayer path/to/file or do
>> I need to add some options so that it will provide more info?
>>     
>
> If you run mplayer <file> it will try to autodetect what to do. Or you can 
> look at the kmpayer config and find the corresponding options in mplayer's man 
> page and use those to see if it makes a difference.
>
> Beware the mplayer man page - it's huge, complex and a horrendous read. That's 
> unavoidable - happens with any complex software that covers 100s of possible 
> combinations.
>
>   

I noticed it was huge.  That was why I asked.  I figured a reply might
be faster than me trying to read all that then understand it as well. 
That could take a looooooong while.  LOL

Dale

:-)  :-) 

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Jesús Guerrero]

On Fri, 30 Oct 2009 22:34:57 -0500, Dale <rdalek1967@gmail.com> wrote:
> Jesús Guerrero wrote:
>>
>> kmplayer can get in the middle, can you -please- test regular mplayer
>> from
>> command line?
>>
>> I've had a similar issue a couple of weeks ago, and we were able to
track
>> it down on the mplayer mailing lists. If it's the same bug, I was able
to
>> consistently reproduce it in streams with ac3 (5.1) audio (stereo
worked
>> fine), and only when using ALSA. So, check that and see if you can see
a
>> pattern there. If you see that same pattern, then it might be the same
>> bug,
>> it's been fixed in the development branch, and the following ebuilds
>> should
>> work fine:
>>
>> 1.0_rc4_p20091026, 1.0_rc4_p20091026-r1, 9999
>>
>> If not, then it's probably something else. But try with mplayer alone
>> when
>> debugging, since kmplayer just adds another level to worry about. For
>> your
>> reference, here's the bug I opened, there you can also find links to
the
>> relevant mails in the mplayer ML.
>>
>> http://bugs.gentoo.org/show_bug.cgi?id=286020
>>
>>   
> 
> I can give it a shot at least.  Do I just run mplayer path/to/file or do
> I need to add some options so that it will provide more info?

Sorry for the delay, it's been a busy weekend ;)

You can just run "mplayer <file>", if you need to force ALSA (so you can
check if it's a problem with ALSA as it was my case) you can add -ao alsa,
so it would be:

  mplayer -ao alsa <filename>

Mplayer is usually smart enough to decide what to do without any further
action on the user's side, however as someone said it's a very complex
program that can do almost anything in which regards playing media files,
that's why the man page is such a huge beast. If we manage to identify the
bug and reproduce it consistently then that's a huge step towards finding a
solution.

By the way, what mplayer version are you using?
-- 
Jesús Guerrero

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Jesús Guerrero wrote:
> On Fri, 30 Oct 2009 22:34:57 -0500, Dale <rdalek1967@gmail.com> wrote:
>   
>> Jesús Guerrero wrote:
>>     
>>> kmplayer can get in the middle, can you -please- test regular mplayer
>>> from
>>> command line?
>>>
>>> I've had a similar issue a couple of weeks ago, and we were able to
>>>       
> track
>   
>>> it down on the mplayer mailing lists. If it's the same bug, I was able
>>>       
> to
>   
>>> consistently reproduce it in streams with ac3 (5.1) audio (stereo
>>>       
> worked
>   
>>> fine), and only when using ALSA. So, check that and see if you can see
>>>       
> a
>   
>>> pattern there. If you see that same pattern, then it might be the same
>>> bug,
>>> it's been fixed in the development branch, and the following ebuilds
>>> should
>>> work fine:
>>>
>>> 1.0_rc4_p20091026, 1.0_rc4_p20091026-r1, 9999
>>>
>>> If not, then it's probably something else. But try with mplayer alone
>>> when
>>> debugging, since kmplayer just adds another level to worry about. For
>>> your
>>> reference, here's the bug I opened, there you can also find links to
>>>       
> the
>   
>>> relevant mails in the mplayer ML.
>>>
>>> http://bugs.gentoo.org/show_bug.cgi?id=286020
>>>
>>>   
>>>       
>> I can give it a shot at least.  Do I just run mplayer path/to/file or do
>> I need to add some options so that it will provide more info?
>>     
>
> Sorry for the delay, it's been a busy weekend ;)
>
> You can just run "mplayer <file>", if you need to force ALSA (so you can
> check if it's a problem with ALSA as it was my case) you can add -ao alsa,
> so it would be:
>
>   mplayer -ao alsa <filename>
>
> Mplayer is usually smart enough to decide what to do without any further
> action on the user's side, however as someone said it's a very complex
> program that can do almost anything in which regards playing media files,
> that's why the man page is such a huge beast. If we manage to identify the
> bug and reproduce it consistently then that's a huge step towards finding a
> solution.
>
> By the way, what mplayer version are you using?
>   

This is the emerge info for mplayer and ffmpeg since that is what it is
using:

root@smoker / # emerge -pv mplayer ffmpeg

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] media-video/ffmpeg-0.5-r1  USE="3dnow 3dnowext X alsa
encode hardcoded-tables ipv6 jpeg2k mmx mmxext mp3 sdl ssse3 vorbis x264
xvid zlib (-altivec) -amr -bindist -custom-cflags -debug -dirac -doc
-faac -faad -gsm -ieee1394 -network -oss -schroedinger -speex -test
-theora -threads -v4l -v4l2 -vdpau -vhook" VIDEO_CARDS="nvidia" 0 kB
[ebuild   R   ] media-video/mplayer-1.0_rc2_p20090731  USE="3dnow X aac
alsa ass cddb cdio dirac dv dvd dvdnav enca encode esd faac faad gif
iconv ipv6 jpeg live mad mmx mng mp2 mp3 network opengl osdmenu png
quicktime rar real rtc schroedinger sdl shm speex sse tremor truetype
unicode vorbis win32codecs x264 xscreensaver xv xvid -3dnowext -a52
-aalib (-altivec) -bidi -bindist -bl -cdparanoia -cpudetection
-custom-cflags -custom-cpuopts -debug -dga -directfb -doc -dts -dvb
-dxr3 -fbcon -ftp -ggi -gmplayer -jack -joystick -ladspa -libcaca -lirc
-lzo -md5sum -mmxext -nas -openal -oss -pnm -pulseaudio -pvr -radio
-samba -sse2 -ssse3 -svga -teletext -tga -theora -v4l -v4l2 -vdpau
-vidix -xanim -xinerama -xvmc -zoran" VIDEO_CARDS="nvidia -mga -s3virge
-tdfx -vesa" 0 kB

Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
root@smoker / #

Those version OK?  I am also still using KDE 3.5.  KDE4 is just not
there yet for me. 

Dale

:-)  :-) 

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Jesús Guerrero]

On Sun, 01 Nov 2009 12:21:32 -0600, Dale <rdalek1967@gmail.com> wrote:
> Jesús Guerrero wrote:
>> On Fri, 30 Oct 2009 22:34:57 -0500, Dale <rdalek1967@gmail.com> wrote:
>>   
>>> Jesús Guerrero wrote:
>>>     
>>>> kmplayer can get in the middle, can you -please- test regular mplayer
>>>> from
>>>> command line?
>>>>
>>>> I've had a similar issue a couple of weeks ago, and we were able to
>>>>       
>> track
>>   
>>>> it down on the mplayer mailing lists. If it's the same bug, I was
able
>>>>       
>> to
>>   
>>>> consistently reproduce it in streams with ac3 (5.1) audio (stereo
>>>>       
>> worked
>>   
>>>> fine), and only when using ALSA. So, check that and see if you can
see
>>>>       
>> a
>>   
>>>> pattern there. If you see that same pattern, then it might be the
same
>>>> bug,
>>>> it's been fixed in the development branch, and the following ebuilds
>>>> should
>>>> work fine:
>>>>
>>>> 1.0_rc4_p20091026, 1.0_rc4_p20091026-r1, 9999
>>>>
>>>> If not, then it's probably something else. But try with mplayer alone
>>>> when
>>>> debugging, since kmplayer just adds another level to worry about. For
>>>> your
>>>> reference, here's the bug I opened, there you can also find links to
>>>>       
>> the
>>   
>>>> relevant mails in the mplayer ML.
>>>>
>>>> http://bugs.gentoo.org/show_bug.cgi?id=286020
>>>>
>>>>   
>>>>       
>>> I can give it a shot at least.  Do I just run mplayer path/to/file or
do
>>> I need to add some options so that it will provide more info?
>>>     
>>
>> Sorry for the delay, it's been a busy weekend ;)
>>
>> You can just run "mplayer <file>", if you need to force ALSA (so you
can
>> check if it's a problem with ALSA as it was my case) you can add -ao
>> alsa,
>> so it would be:
>>
>>   mplayer -ao alsa <filename>
>>
>> Mplayer is usually smart enough to decide what to do without any
further
>> action on the user's side, however as someone said it's a very complex
>> program that can do almost anything in which regards playing media
files,
>> that's why the man page is such a huge beast. If we manage to identify
>> the
>> bug and reproduce it consistently then that's a huge step towards
>> finding a
>> solution.
>>
>> By the way, what mplayer version are you using?
>>   
> 
> This is the emerge info for mplayer and ffmpeg since that is what it is
> using:
> 
> root@smoker / # emerge -pv mplayer ffmpeg
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ] media-video/ffmpeg-0.5-r1  USE="3dnow 3dnowext X alsa
> encode hardcoded-tables ipv6 jpeg2k mmx mmxext mp3 sdl ssse3 vorbis x264
> xvid zlib (-altivec) -amr -bindist -custom-cflags -debug -dirac -doc
> -faac -faad -gsm -ieee1394 -network -oss -schroedinger -speex -test
> -theora -threads -v4l -v4l2 -vdpau -vhook" VIDEO_CARDS="nvidia" 0 kB
> [ebuild   R   ] media-video/mplayer-1.0_rc2_p20090731  USE="3dnow X aac
> alsa ass cddb cdio dirac dv dvd dvdnav enca encode esd faac faad gif
> iconv ipv6 jpeg live mad mmx mng mp2 mp3 network opengl osdmenu png
> quicktime rar real rtc schroedinger sdl shm speex sse tremor truetype
> unicode vorbis win32codecs x264 xscreensaver xv xvid -3dnowext -a52
> -aalib (-altivec) -bidi -bindist -bl -cdparanoia -cpudetection
> -custom-cflags -custom-cpuopts -debug -dga -directfb -doc -dts -dvb
> -dxr3 -fbcon -ftp -ggi -gmplayer -jack -joystick -ladspa -libcaca -lirc
> -lzo -md5sum -mmxext -nas -openal -oss -pnm -pulseaudio -pvr -radio
> -samba -sse2 -ssse3 -svga -teletext -tga -theora -v4l -v4l2 -vdpau
> -vidix -xanim -xinerama -xvmc -zoran" VIDEO_CARDS="nvidia -mga -s3virge
> -tdfx -vesa" 0 kB
> 
> Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
> root@smoker / #
> 
> Those version OK?  I am also still using KDE 3.5.  KDE4 is just not
> there yet for me. 

As far as I know that version of mplayer is bugged. I can't guarantee that
your problem is the same one I had, but if I am not mistaken the bug is
present in that release. Please, try 1.0_rc4_p20091026-r1 and see if the
bug goes away. I will open an STABLEREQ bug to speed up the stabilization
of this version, and the masking of older ones. After all, they should be
hard masked or at least patched to fix the bug.

-- 
Jesús Guerrero

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Jesús Guerrero wrote:
> On Sun, 01 Nov 2009 12:21:32 -0600, Dale <rdalek1967@gmail.com> wrote:
>   
>> Jesús Guerrero wrote:
>>     
>>> On Fri, 30 Oct 2009 22:34:57 -0500, Dale <rdalek1967@gmail.com> wrote:
>>>   
>>>       
>>>> Jesús Guerrero wrote:
>>>>     
>>>>         
>>>>> kmplayer can get in the middle, can you -please- test regular mplayer
>>>>> from
>>>>> command line?
>>>>>
>>>>> I've had a similar issue a couple of weeks ago, and we were able to
>>>>>       
>>>>>           
>>> track
>>>   
>>>       
>>>>> it down on the mplayer mailing lists. If it's the same bug, I was
>>>>>           
> able
>   
>>>>>       
>>>>>           
>>> to
>>>   
>>>       
>>>>> consistently reproduce it in streams with ac3 (5.1) audio (stereo
>>>>>       
>>>>>           
>>> worked
>>>   
>>>       
>>>>> fine), and only when using ALSA. So, check that and see if you can
>>>>>           
> see
>   
>>>>>       
>>>>>           
>>> a
>>>   
>>>       
>>>>> pattern there. If you see that same pattern, then it might be the
>>>>>           
> same
>   
>>>>> bug,
>>>>> it's been fixed in the development branch, and the following ebuilds
>>>>> should
>>>>> work fine:
>>>>>
>>>>> 1.0_rc4_p20091026, 1.0_rc4_p20091026-r1, 9999
>>>>>
>>>>> If not, then it's probably something else. But try with mplayer alone
>>>>> when
>>>>> debugging, since kmplayer just adds another level to worry about. For
>>>>> your
>>>>> reference, here's the bug I opened, there you can also find links to
>>>>>       
>>>>>           
>>> the
>>>   
>>>       
>>>>> relevant mails in the mplayer ML.
>>>>>
>>>>> http://bugs.gentoo.org/show_bug.cgi?id=286020
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> I can give it a shot at least.  Do I just run mplayer path/to/file or
>>>>         
> do
>   
>>>> I need to add some options so that it will provide more info?
>>>>     
>>>>         
>>> Sorry for the delay, it's been a busy weekend ;)
>>>
>>> You can just run "mplayer <file>", if you need to force ALSA (so you
>>>       
> can
>   
>>> check if it's a problem with ALSA as it was my case) you can add -ao
>>> alsa,
>>> so it would be:
>>>
>>>   mplayer -ao alsa <filename>
>>>
>>> Mplayer is usually smart enough to decide what to do without any
>>>       
> further
>   
>>> action on the user's side, however as someone said it's a very complex
>>> program that can do almost anything in which regards playing media
>>>       
> files,
>   
>>> that's why the man page is such a huge beast. If we manage to identify
>>> the
>>> bug and reproduce it consistently then that's a huge step towards
>>> finding a
>>> solution.
>>>
>>> By the way, what mplayer version are you using?
>>>   
>>>       
>> This is the emerge info for mplayer and ffmpeg since that is what it is
>> using:
>>
>> root@smoker / # emerge -pv mplayer ffmpeg
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild   R   ] media-video/ffmpeg-0.5-r1  USE="3dnow 3dnowext X alsa
>> encode hardcoded-tables ipv6 jpeg2k mmx mmxext mp3 sdl ssse3 vorbis x264
>> xvid zlib (-altivec) -amr -bindist -custom-cflags -debug -dirac -doc
>> -faac -faad -gsm -ieee1394 -network -oss -schroedinger -speex -test
>> -theora -threads -v4l -v4l2 -vdpau -vhook" VIDEO_CARDS="nvidia" 0 kB
>> [ebuild   R   ] media-video/mplayer-1.0_rc2_p20090731  USE="3dnow X aac
>> alsa ass cddb cdio dirac dv dvd dvdnav enca encode esd faac faad gif
>> iconv ipv6 jpeg live mad mmx mng mp2 mp3 network opengl osdmenu png
>> quicktime rar real rtc schroedinger sdl shm speex sse tremor truetype
>> unicode vorbis win32codecs x264 xscreensaver xv xvid -3dnowext -a52
>> -aalib (-altivec) -bidi -bindist -bl -cdparanoia -cpudetection
>> -custom-cflags -custom-cpuopts -debug -dga -directfb -doc -dts -dvb
>> -dxr3 -fbcon -ftp -ggi -gmplayer -jack -joystick -ladspa -libcaca -lirc
>> -lzo -md5sum -mmxext -nas -openal -oss -pnm -pulseaudio -pvr -radio
>> -samba -sse2 -ssse3 -svga -teletext -tga -theora -v4l -v4l2 -vdpau
>> -vidix -xanim -xinerama -xvmc -zoran" VIDEO_CARDS="nvidia -mga -s3virge
>> -tdfx -vesa" 0 kB
>>
>> Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
>> root@smoker / #
>>
>> Those version OK?  I am also still using KDE 3.5.  KDE4 is just not
>> there yet for me. 
>>     
>
> As far as I know that version of mplayer is bugged. I can't guarantee that
> your problem is the same one I had, but if I am not mistaken the bug is
> present in that release. Please, try 1.0_rc4_p20091026-r1 and see if the
> bug goes away. I will open an STABLEREQ bug to speed up the stabilization
> of this version, and the masking of older ones. After all, they should be
> hard masked or at least patched to fix the bug.
>
>   

I'll unmask and keyword if needed to get the latest version.  I have
noticed that if my CPU is not to busy, it does a lot better but appears
to be a half second off or so even if fairly idle.  It still varies by
the file type tho.  I use Firefox and the download helper extension to
both download and convert the files to mpg4.  I set it to "same quality"
and that seems to help a LOT and the files are larger.  It uses ffmpeg
to convert the files.  I convert them in case I send a video to a
windoze user.  My brother can't get a .flv to play except through a
website.  I dunno.  Its windoze.  LOL

Dale

:-)  :-) 

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Jesús Guerrero wrote:
>
> As far as I know that version of mplayer is bugged. I can't guarantee that
> your problem is the same one I had, but if I am not mistaken the bug is
> present in that release. Please, try 1.0_rc4_p20091026-r1 and see if the
> bug goes away. I will open an STABLEREQ bug to speed up the stabilization
> of this version, and the masking of older ones. After all, they should be
> hard masked or at least patched to fix the bug.
>
>   

Well, this opened a can of worms.  After doing that upgrade, I get a
endless loop of preserved-rebuilds.  Here is the list that I keep going
in circles with:

     Sun Nov  1 17:22:11 2009 >>> media-libs/x264-0.0.20091021
     Sun Nov  1 17:35:33 2009 >>> media-video/mplayer-1.0_rc4_p20091026-r1
     Sun Nov  1 18:25:39 2009 >>> media-libs/x264-0.0.20081006
     Sun Nov  1 18:29:09 2009 >>> media-libs/libquicktime-1.1.3
     Sun Nov  1 18:47:44 2009 >>> media-video/avidemux-2.4.4-r2
     Sun Nov  1 18:58:11 2009 >>> media-video/ffmpeg-0.5-r1
     Sun Nov  1 21:35:58 2009 >>> media-libs/x264-0.0.20091021
     Sun Nov  1 21:48:19 2009 >>> media-video/mplayer-1.0_rc4_p20091026-r1
     Sun Nov  1 22:25:58 2009 >>> media-libs/x264-0.0.20081006
     Sun Nov  1 22:29:24 2009 >>> media-libs/libquicktime-1.1.3
     Sun Nov  1 22:47:44 2009 >>> media-video/avidemux-2.4.4-r2
     Sun Nov  1 22:58:09 2009 >>> media-video/ffmpeg-0.5-r1
root@smoker / #                                               

It just seems to go round and round.  Ideas? 

Dale

:-)  :-)

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Jesús Guerrero]

On Mon, 02 Nov 2009 00:08:01 -0600, Dale <rdalek1967@gmail.com> wrote:
> Jesús Guerrero wrote:
>>
>> As far as I know that version of mplayer is bugged. I can't guarantee
>> that
>> your problem is the same one I had, but if I am not mistaken the bug is
>> present in that release. Please, try 1.0_rc4_p20091026-r1 and see if
the
>> bug goes away. I will open an STABLEREQ bug to speed up the
stabilization
>> of this version, and the masking of older ones. After all, they should
be
>> hard masked or at least patched to fix the bug.
>>
>>   
> 
> Well, this opened a can of worms.  After doing that upgrade, I get a
> endless loop of preserved-rebuilds.  Here is the list that I keep going
> in circles with:
> 
>      Sun Nov  1 17:22:11 2009 >>> media-libs/x264-0.0.20091021
>      Sun Nov  1 17:35:33 2009 >>>
media-video/mplayer-1.0_rc4_p20091026-r1
>      Sun Nov  1 18:25:39 2009 >>> media-libs/x264-0.0.20081006
>      Sun Nov  1 18:29:09 2009 >>> media-libs/libquicktime-1.1.3
>      Sun Nov  1 18:47:44 2009 >>> media-video/avidemux-2.4.4-r2
>      Sun Nov  1 18:58:11 2009 >>> media-video/ffmpeg-0.5-r1
>      Sun Nov  1 21:35:58 2009 >>> media-libs/x264-0.0.20091021
>      Sun Nov  1 21:48:19 2009 >>>
media-video/mplayer-1.0_rc4_p20091026-r1
>      Sun Nov  1 22:25:58 2009 >>> media-libs/x264-0.0.20081006
>      Sun Nov  1 22:29:24 2009 >>> media-libs/libquicktime-1.1.3
>      Sun Nov  1 22:47:44 2009 >>> media-video/avidemux-2.4.4-r2
>      Sun Nov  1 22:58:09 2009 >>> media-video/ffmpeg-0.5-r1
> root@smoker / #                                               
> 
> It just seems to go round and round.  Ideas? 

@preserved-rebuild never worked for me, maybe it's just that it doesn't
like ~arch. I am just too lazy to work on how to fix a thing when there's
an alternative that always worked reliably, revdep-rebuild.

-- 
Jesús Guerrero

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote:

> @preserved-rebuild never worked for me, maybe it's just that it doesn't
> like ~arch. I am just too lazy to work on how to fix a thing when
> there's an alternative that always worked reliably, revdep-rebuild.

If it didn't work on ~arch, how would it ever make it into arch?

The trouble with revdep-rebuild is that you have to break your system and
then fix it. Most of the time this is trivial, but updates like expat-2.0
showed the usefulness of being able to recompile the packages before they
were broken.


-- 
Neil Bothwick

Ultimate memory manager; Windows, it manages to use it all..

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Dale]

Neil Bothwick wrote:
> On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote:
>
>   
>> @preserved-rebuild never worked for me, maybe it's just that it doesn't
>> like ~arch. I am just too lazy to work on how to fix a thing when
>> there's an alternative that always worked reliably, revdep-rebuild.
>>     
>
> If it didn't work on ~arch, how would it ever make it into arch?
>
> The trouble with revdep-rebuild is that you have to break your system and
> then fix it. Most of the time this is trivial, but updates like expat-2.0
> showed the usefulness of being able to recompile the packages before they
> were broken.
>
>
>   

Whatever it was, a sync and -uvDN world fixeded it.  It didn't want to
rebuild anything afterwards so I guess I caught the tree in the middle
of a time shift or something. 

I'll do some testing here before to long.  Oh, I went to my brothers and
watched a couple videos on his rig.  He has windoze, poor thang. 
Anyway, his is a little off too.  It may be something other than my box
and mplayer.  It's off about the same amount too.

Is it possible to record them with it off a bit?

Dale

:-)  :-) 

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Jesús Guerrero]

On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick <neil@digimed.co.uk>
wrote:
> On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote:
> 
>> @preserved-rebuild never worked for me, maybe it's just that it doesn't
>> like ~arch. I am just too lazy to work on how to fix a thing when
>> there's an alternative that always worked reliably, revdep-rebuild.
> 
> If it didn't work on ~arch, how would it ever make it into arch?
> 
I am not the one to answer that, all I can say is that the few times I've
tried it, it kept rebuilding the same  packages again, and again, and again
ad infinitum, as said, I didn't even bother to find what the problem was,
because I have a working alternative. Sure it could be better, but that
hasn't been the case for me with @preserved-rebuild.

I've seen people reporting the same problems in the forums, so I am fairly
sure that's a common problem and not just exclusive to my installations.

> The trouble with revdep-rebuild is that you have to break your system
and
> then fix it. Most of the time this is trivial, but updates like
expat-2.0
> showed the usefulness of being able to recompile the packages before
they
> were broken.

I can't understand that. You CAN'T recompile your packages against the new
ABI's until the new ABI is in your system, and hence your system is already
broken. There's no preemptive measure against this. Both methods fix the
system *after* it's broken.

-- 
Jesús Guerrero

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Alan McKinnon]

On Monday 02 November 2009 15:58:57 Jesús Guerrero wrote:
> On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick <neil@digimed.co.uk>
> 
> wrote:
> > On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote:
> >> @preserved-rebuild never worked for me, maybe it's just that it doesn't
> >> like ~arch. I am just too lazy to work on how to fix a thing when
> >> there's an alternative that always worked reliably, revdep-rebuild.
> >
> > If it didn't work on ~arch, how would it ever make it into arch?
> 
> I am not the one to answer that, all I can say is that the few times I've
> tried it, it kept rebuilding the same  packages again, and again, and again
> ad infinitum, as said, I didn't even bother to find what the problem was,
> because I have a working alternative. Sure it could be better, but that
> hasn't been the case for me with @preserved-rebuild.
> 
> I've seen people reporting the same problems in the forums, so I am fairly
> sure that's a common problem and not just exclusive to my installations.
> 
> > The trouble with revdep-rebuild is that you have to break your system
> 
> and
> 
> > then fix it. Most of the time this is trivial, but updates like
> 
> expat-2.0
> 
> > showed the usefulness of being able to recompile the packages before
> 
> they
> 
> > were broken.
> 
> I can't understand that. You CAN'T recompile your packages against the new
> ABI's until the new ABI is in your system, and hence your system is already
> broken. There's no preemptive measure against this. Both methods fix the
> system *after* it's broken.

Unless the old and the new ABI version are installed side by side. When 
@preserved-rebuild is run, it deletes the old libs only after everything left 
that used it is now linked against the new one.

There's only one case where this can't work - the developer changes the ABI 
and does not change the .so version number. That ain't gentoo's fault - shoot 
the developer.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Kmplayer, video and audio not syncing.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

On Mon, 02 Nov 2009 14:58:57 +0100, Jesús Guerrero wrote:

> I can't understand that. You CAN'T recompile your packages against the
> new ABI's until the new ABI is in your system, and hence your system is
> already broken. There's no preemptive measure against this. Both
> methods fix the system *after* it's broken.

There's a lot of things I don't understand, it doesn't make then wrong :-O


-- 
Neil Bothwick

DOS Tip #17: Add DEVICE=FNGRCROS.SYS to CONFIG.SYS

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]

[Jesús Guerrero]

On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon <alan.mckinnon@gmail.com>
wrote:
> On Monday 02 November 2009 15:58:57 Jesús Guerrero wrote:
>> On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick <neil@digimed.co.uk>
>> 
>> wrote:
>> > On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote:
>> >> @preserved-rebuild never worked for me, maybe it's just that it
>> >> doesn't
>> >> like ~arch. I am just too lazy to work on how to fix a thing when
>> >> there's an alternative that always worked reliably, revdep-rebuild.
>> >
>> > If it didn't work on ~arch, how would it ever make it into arch?
>> 
>> I am not the one to answer that, all I can say is that the few times
I've
>> tried it, it kept rebuilding the same  packages again, and again, and
>> again
>> ad infinitum, as said, I didn't even bother to find what the problem
was,
>> because I have a working alternative. Sure it could be better, but that
>> hasn't been the case for me with @preserved-rebuild.
>> 
>> I've seen people reporting the same problems in the forums, so I am
>> fairly
>> sure that's a common problem and not just exclusive to my
installations.
>> 
>> > The trouble with revdep-rebuild is that you have to break your system
>> 
>> and
>> 
>> > then fix it. Most of the time this is trivial, but updates like
>> 
>> expat-2.0
>> 
>> > showed the usefulness of being able to recompile the packages before
>> 
>> they
>> 
>> > were broken.
>> 
>> I can't understand that. You CAN'T recompile your packages against the
>> new
>> ABI's until the new ABI is in your system, and hence your system is
>> already
>> broken. There's no preemptive measure against this. Both methods fix
the
>> system *after* it's broken.
> 
> Unless the old and the new ABI version are installed side by side. When 
> @preserved-rebuild is run, it deletes the old libs only after everything
> left 
> that used it is now linked against the new one.
 
Thanks for the feedback. However there's one thing I can't understand:
whether the libraries are kept of removed is decided at the merge time,
isn't it? So, whatever breaks, breaks when using "emerge" to update the
offending library, the one that will break the ABI. So, how can using a
tool *after that* have any impact over what's broken? It can fix the
problem, but so can revdep-rebuild.

I mean: if the old libs with the old abi's are kept, how it is relevant if
you are using @preserved-rebuild, revdep-rebuild or another method, or none
at all? Your programs will continue to work ok without needing to rebuild
anything, won't them? And after rebuilding the package it's irrelevant
*how* did you rebuild them... I must obviously be missing something here,
if you have the time please, direct me to an adequate source of information
or explain a bit, I am curious.


> There's only one case where this can't work - the developer changes the
> ABI 
> and does not change the .so version number. That ain't gentoo's fault -
> shoot 
> the developer.

Of course, I can understand that.

However and even if @preserved-rebuild has some reason to exist, it still
doesn't fix the weird behavior that it exhibited for me in the past. But to
tell the truth, I haven't tested lately. It just came to mi mind because of
the Dale's problem, which seems to be the same one. Please, understand that
I'm not complaining, merely describing my experience, I'd rather be filling
bugs than complain uselessly, it's just that -as I said- I really didn't
see a need to because the old way just works.

-- 
Jesús Guerrero

Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]

[Alan McKinnon]

On Monday 02 November 2009 17:01:17 Jesús Guerrero wrote:
> On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon <alan.mckinnon@gmail.com>
> 
> wrote:
> > On Monday 02 November 2009 15:58:57 Jesús Guerrero wrote:
> >> On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick <neil@digimed.co.uk>
> >>
> >> wrote:
> >> > On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote:
> >> >> @preserved-rebuild never worked for me, maybe it's just that it
> >> >> doesn't
> >> >> like ~arch. I am just too lazy to work on how to fix a thing when
> >> >> there's an alternative that always worked reliably, revdep-rebuild.
> >> >
> >> > If it didn't work on ~arch, how would it ever make it into arch?
> >>
> >> I am not the one to answer that, all I can say is that the few times
> 
> I've
> 
> >> tried it, it kept rebuilding the same  packages again, and again, and
> >> again
> >> ad infinitum, as said, I didn't even bother to find what the problem
> 
> was,
> 
> >> because I have a working alternative. Sure it could be better, but that
> >> hasn't been the case for me with @preserved-rebuild.
> >>
> >> I've seen people reporting the same problems in the forums, so I am
> >> fairly
> >> sure that's a common problem and not just exclusive to my
> 
> installations.
> 
> >> > The trouble with revdep-rebuild is that you have to break your system
> >>
> >> and
> >>
> >> > then fix it. Most of the time this is trivial, but updates like
> >>
> >> expat-2.0
> >>
> >> > showed the usefulness of being able to recompile the packages before
> >>
> >> they
> >>
> >> > were broken.
> >>
> >> I can't understand that. You CAN'T recompile your packages against the
> >> new
> >> ABI's until the new ABI is in your system, and hence your system is
> >> already
> >> broken. There's no preemptive measure against this. Both methods fix
> 
> the
> 
> >> system *after* it's broken.
> >
> > Unless the old and the new ABI version are installed side by side. When
> > @preserved-rebuild is run, it deletes the old libs only after everything
> > left
> > that used it is now linked against the new one.
> 
> Thanks for the feedback. However there's one thing I can't understand:
> whether the libraries are kept of removed is decided at the merge time,
> isn't it? So, whatever breaks, breaks when using "emerge" to update the
> offending library, the one that will break the ABI. So, how can using a
> tool *after that* have any impact over what's broken? It can fix the
> problem, but so can revdep-rebuild.
> 
> I mean: if the old libs with the old abi's are kept, how it is relevant if
> you are using @preserved-rebuild, revdep-rebuild or another method, or none
> at all? Your programs will continue to work ok without needing to rebuild
> anything, won't them? And after rebuilding the package it's irrelevant
> *how* did you rebuild them... I must obviously be missing something here,
> if you have the time please, direct me to an adequate source of information
> or explain a bit, I am curious.

Easy. Say you have app x which links to lib y:

portage knows that x is linked to say y.1.0.0.so

portage then upgrades y and puts y.so.1.0.1.so and the system helpfully thinks 
to itself "hang on a bit, I'm about to remove a library that Y is using. I'd 
better not do that!" and tells you so. (In the meantime you can merge anything 
you like that links to y.1.0.0.so, this does not affect @preserved-rebuild)

You read the message, run @preserved-rebuild and x now links to the new y 
library. When everything in @preserved-rebuild has been rebuilt, portage knows 
that now nothing links to the old y library, and removes it.

Do you see that the intent is to provide a bridging period where needed libs 
are not missing? And that @preserved-rebuild and revdep-rebuild do essentially 
the same function, except:

1. Stuff does not break. OK, make that "stuff should not break"
2. You don't have to hang around waiting for revdep-rebuild to take ages to 
run

It can go south sometimes, the @preserved-rebuild magic is not always perfect 
and sometimes it gets confused. There's a file in /var somewhere that records 
this, so you can just delete it and run revdep-rebuild to get the old 
behaviour. Sometimes devs do stupid things with what they decide libs are 
called, and there's nothing portage can do about that except get itself 
confused (it's not a human and can't infer meaning).

I've been using @preserved-rebuild for as long as it's been available (more 
than a year now?) with very very few hitches. I think you were just unlucky to 
hit a few stupid packages.


> > There's only one case where this can't work - the developer changes the
> > ABI
> > and does not change the .so version number. That ain't gentoo's fault -
> > shoot
> > the developer.
> 
> Of course, I can understand that.
> 
> However and even if @preserved-rebuild has some reason to exist, it still
> doesn't fix the weird behavior that it exhibited for me in the past. But to
> tell the truth, I haven't tested lately. It just came to mi mind because of
> the Dale's problem, which seems to be the same one. Please, understand that
> I'm not complaining, merely describing my experience, I'd rather be filling
> bugs than complain uselessly, it's just that -as I said- I really didn't
> see a need to because the old way just works.
 
yes, the old way does work. But it has this period in the middle where stuff 
is broken. 

Preserved-rebuild is an effort to do the same thing in a different order, to 
minimize breakage

Of course, my entire understanding of this could be completely wrong. If so, 
someone will correct me :-)

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild

[Graham Murray]

Jesús Guerrero <i92guboj@terra.es> writes:

> Thanks for the feedback. However there's one thing I can't understand:
> whether the libraries are kept of removed is decided at the merge time,
> isn't it? So, whatever breaks, breaks when using "emerge" to update the
> offending library, the one that will break the ABI. So, how can using a
> tool *after that* have any impact over what's broken? It can fix the
> problem, but so can revdep-rebuild.
>
> I mean: if the old libs with the old abi's are kept, how it is relevant if
> you are using @preserved-rebuild, revdep-rebuild or another method, or none
> at all? Your programs will continue to work ok without needing to rebuild
> anything, won't them? And after rebuilding the package it's irrelevant
> *how* did you rebuild them... I must obviously be missing something here,
> if you have the time please, direct me to an adequate source of information
> or explain a bit, I am curious.

The difference is that with the new @preserved-rebuild the 'old' library
is not deleted until all of the dependent packages have been
successfully rebuilt to use the 'new' library. With the old
revdep-rebuild mechanism, the 'old' library was deleted during the
upgrade emerge. Therefore after the new library was merged, packages
which depended on the old library could not be run[1] until these
dependent packages were rebuilt to use the new library.

[1] Though any which were running at the time the new library was merged
would continue to run. 

Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]

[Alex Schuster]

Jesús Guerrero writes:

> On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon
>  <alan.mckinnon@gmail.com> wrote:
> > On Monday 02 November 2009 15:58:57 Jesús Guerrero wrote:
> >> On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick <neil@digimed.co.uk>
> >> wrote:
> >> > On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote:
> >> >> @preserved-rebuild never worked for me, maybe it's just that it
> >> >> doesn't like ~arch. I am just too lazy to work on how to fix a
> >> >> thing when there's an alternative that always worked reliably,
> >> >> revdep-rebuild.

I like the preserve-libs FEATURE. With revdep-rebuild, things are fixed 
after they were broken by an update of a library. And there is a time (in 
case of the dreaded expat update, a large one, expecially if revdep-
rebuilding stuff fails for some packages) in which things do not work. I 
always hated that and considered it a serious bug.
With preserve-libs, things do not break in the first place, because the old 
libraries are still in place.

> >> > If it didn't work on ~arch, how would it ever make it into arch?
> >>
> >> I am not the one to answer that, all I can say is that the few times
> >> I've tried it, it kept rebuilding the same  packages again, and 
> >> again, and again ad infinitum, as said, I didn't even bother to find
> >> what the problem was, because I have a working alternative. Sure it
> >> could be better, but that hasn't been the case for me with 
> >> @preserved-rebuild.

I had the same problem with emerge @preserved-rebuild looping endlessly, 
but that's probably just a minor issue. Just use emerge @preserved-rebuild 
once to make sure the new libs are being used, and remove 
/var/lib/portage/preserved_libs_registry afterwards to get rid of the 
preserved-libs message.


> >> > The trouble with revdep-rebuild is that you have to break your
> >> > system and then fix it. Most of the time this is trivial, but
> >> > updates like expat-2.0 showed the usefulness of being able to
> >> > recompile the packages before they were broken.
> >>
> >> I can't understand that. You CAN'T recompile your packages against
> >> the new ABI's until the new ABI is in your system, and hence your
> >> system is already broken. There's no preemptive measure against
> >> this. Both methods fix the system *after* it's broken.
> >
> > Unless the old and the new ABI version are installed side by side. When
> > @preserved-rebuild is run, it deletes the old libs only after
> > everything left that used it is now linked against the new one.
> 
> Thanks for the feedback. However there's one thing I can't understand:
> whether the libraries are kept of removed is decided at the merge time,
> isn't it? So, whatever breaks, breaks when using "emerge" to update the
> offending library, the one that will break the ABI. So, how can using a
> tool *after that* have any impact over what's broken? It can fix the
> problem, but so can revdep-rebuild.

Again, things do not break in the first place with the preserved-rebuild 
FEATURE. As a library gets updated, the new library is installed along with 
the old one. Applications linked to the old one still work. When they are 
re-compiled, the are linked to the new library, making the old libraries 
obsolete when this is done for all packages depending on them.

> I mean: if the old libs with the old abi's are kept, how it is relevant
>  if you are using @preserved-rebuild, revdep-rebuild or another method,
>  or none at all? Your programs will continue to work ok without needing
>  to rebuild anything, won't them? And after rebuilding the package it's
>  irrelevant *how* did you rebuild them... I must obviously be missing
>  something here, if you have the time please, direct me to an adequate
>  source of information or explain a bit, I am curious.

I think the revdep-rebuild way would not work here. I assume it uses ldd to 
check all binaries for existance of their libraries, and rebuild them if 
there are problems. When the old libraries are still in place, there is no 
problem for ldd, and nothing gets re-compiled. No big problem, but you 
clutter your system with old libraries staying in place, and programs still 
using them do not take possible advantage ob the newer libraries.

	Wonko

[gentoo-user] Re: revdep-rebuild vs. @preserved-rebuild

[Harry Putnam]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> You read the message, run @preserved-rebuild and x now links to the new y 
> library. When everything in @preserved-rebuild has been rebuilt, portage knows 
> that now nothing links to the old y library, and removes it.

Alan, I haven't followed the introduction of @preserved-rebuild, but
you comments make sound like something that happens as emerge is
running.

Or is it use like its predecessor and ran after a large merge or update?

Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]

[Jesús Guerrero]

Thanks everyone for the input, it's being quite informative and valuable.
I guess I'll have to research on this at some point. Still I'd like to keep
responses coming if anyone can bring some light into the issue. :)

I am responding only to one post, but I've read Alan's one as well, as
said, thanks to everyone that answered.

On Mon, 2 Nov 2009 16:50:19 +0100, Alex Schuster <wonko@wonkology.org>
wrote:
> Jesús Guerrero writes:
> 
>> On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon
>>  <alan.mckinnon@gmail.com> wrote:
>> > On Monday 02 November 2009 15:58:57 Jesús Guerrero wrote:
>> >> On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick
<neil@digimed.co.uk>
>> >> wrote:
>> >> > On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote:
>> >> >> @preserved-rebuild never worked for me, maybe it's just that it
>> >> >> doesn't like ~arch. I am just too lazy to work on how to fix a
>> >> >> thing when there's an alternative that always worked reliably,
>> >> >> revdep-rebuild.
> 
> I like the preserve-libs FEATURE. With revdep-rebuild, things are fixed 
> after they were broken by an update of a library. And there is a time
(in 
> case of the dreaded expat update, a large one, expecially if revdep-
> rebuilding stuff fails for some packages) in which things do not work. I

> always hated that and considered it a serious bug.
> With preserve-libs, things do not break in the first place, because the
> old 
> libraries are still in place.

Ok, well, then the libs are preserved at merge time. Using Alan's analogy,
when you update the lib to y.1.0.1.so. It is *at this time* when y.1.0.0 is
kept, and that has nothing with using "emerge @preserved-rebuild" *in the
future*. You could still use revdep-rebuild and the effect will be the same
(except that old libs will not ever be cleaned if I got it right). Right?
So, it's not "emerge @preserved-rebuild" which fixes the problem (as I
said, by the time you run "emerge @preserved-rebuild" it's already too
late, by then the libs are either preserved or broken), but a whole new
portage behavior, which is quite different. And maybe only if you have a
given FEATURE enabled, which takes this even more far away from the
@revdep-rebuild set.

So, if this all is correct, this set is intended to *fix* the breakage,
just like revdep-rebuild, and *not to prevent* it. It's portage which
prevents it by preserving all .so files. Note that revdep-rebuild didn't
break anything either. That's false. revdep-rebuild only fixes what portage
breaks. It all comes down to one thing: are you using the preserve feature
or not? And not the tool you use to fix the binaries.

> 
>> >> > If it didn't work on ~arch, how would it ever make it into arch?
>> >>
>> >> I am not the one to answer that, all I can say is that the few times
>> >> I've tried it, it kept rebuilding the same  packages again, and 
>> >> again, and again ad infinitum, as said, I didn't even bother to find
>> >> what the problem was, because I have a working alternative. Sure it
>> >> could be better, but that hasn't been the case for me with 
>> >> @preserved-rebuild.
> 
> I had the same problem with emerge @preserved-rebuild looping endlessly,

> but that's probably just a minor issue. Just use emerge
@preserved-rebuild 
> once to make sure the new libs are being used, and remove 
> /var/lib/portage/preserved_libs_registry afterwards to get rid of the 
> preserved-libs message.

That's good to know. However this needs to be fixed, which is probably one
of the reasons why portage 2.2 is taking quite a bit to be released.

>> >> > The trouble with revdep-rebuild is that you have to break your
>> >> > system and then fix it. Most of the time this is trivial, but
>> >> > updates like expat-2.0 showed the usefulness of being able to
>> >> > recompile the packages before they were broken.
>> >>
>> >> I can't understand that. You CAN'T recompile your packages against
>> >> the new ABI's until the new ABI is in your system, and hence your
>> >> system is already broken. There's no preemptive measure against
>> >> this. Both methods fix the system *after* it's broken.
>> >
>> > Unless the old and the new ABI version are installed side by side.
When
>> > @preserved-rebuild is run, it deletes the old libs only after
>> > everything left that used it is now linked against the new one.
>> 
>> Thanks for the feedback. However there's one thing I can't understand:
>> whether the libraries are kept of removed is decided at the merge time,
>> isn't it? So, whatever breaks, breaks when using "emerge" to update the
>> offending library, the one that will break the ABI. So, how can using a
>> tool *after that* have any impact over what's broken? It can fix the
>> problem, but so can revdep-rebuild.
> 
> Again, things do not break in the first place with the preserved-rebuild

> FEATURE. As a library gets updated, the new library is installed along
> with 
> the old one. Applications linked to the old one still work. When they
are 
> re-compiled, the are linked to the new library, making the old libraries

> obsolete when this is done for all packages depending on them.
> 
>> I mean: if the old libs with the old abi's are kept, how it is relevant
>>  if you are using @preserved-rebuild, revdep-rebuild or another method,
>>  or none at all? Your programs will continue to work ok without needing
>>  to rebuild anything, won't them? And after rebuilding the package it's
>>  irrelevant *how* did you rebuild them... I must obviously be missing
>>  something here, if you have the time please, direct me to an adequate
>>  source of information or explain a bit, I am curious.
> 
> I think the revdep-rebuild way would not work here. I assume it uses ldd
> to 
> check all binaries for existance of their libraries, and rebuild them if

> there are problems. When the old libraries are still in place, there is
no 
> problem for ldd, and nothing gets re-compiled. No big problem, but you 
> clutter your system with old libraries staying in place, and programs
> still 
> using them do not take possible advantage ob the newer libraries.


Thanks, these two paragraphs seem to confirm my thoughts above. I finally
understand what this is about :)

-- 
Jesús Guerrero

Re: [gentoo-user] Re: revdep-rebuild vs. @preserved-rebuild

[Alan McKinnon]

On Monday 02 November 2009 18:31:50 Harry Putnam wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> writes:
> > You read the message, run @preserved-rebuild and x now links to the new y
> > library. When everything in @preserved-rebuild has been rebuilt, portage
> > knows that now nothing links to the old y library, and removes it.
> 
> Alan, I haven't followed the introduction of @preserved-rebuild, but
> you comments make sound like something that happens as emerge is
> running.
> 
> Or is it use like its predecessor and ran after a large merge or update?

It all happens invisibly as packages are merged with no user interaction. I 
imagine portage runs ldd or similar on the packages just before installing 
them to the live filesystem - it's quick and I have never noticed any 
slowdown.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Mon, 02 Nov 2009 15:40:35 +0000, Graham Murray wrote:

> The difference is that with the new @preserved-rebuild the 'old' library
> is not deleted until all of the dependent packages have been
> successfully rebuilt to use the 'new' library.

This also means that if you don't run emerge @preserved-rebuild, the old
libraries will still be hanging around, and revdep-rebuild won't rebuild
affected packages because the libraries they link against are still
there. revdep-rebuild depends on packages being broken to rebuild them.


-- 
Neil Bothwick

Lottery: A tax on people who are bad at math.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]