From: SourceForge.net <no...@so...> - 2007-09-07 12:48:18
|
Bugs item #1790087, was opened at 2007-09-07 07:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1790087&group_id=9655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: demuxer (stream type support) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Barber (josiah_barber) Assigned to: Nobody/Anonymous (nobody) Summary: Some MP3's lose first 2 seconds (approx) Initial Comment: Some of my mp3's start playing about 2 seconds into the song. Most mp3's are fine, but I have several in my collection that this happens with. All other mp3 players I have play the files correctly. I narrowed it down to xine-lib-1.1.0 being the last working version of xine-lib. Versions 1.1.1 through 1.1.7 all exhibit the bug. I narrowed it down further to the file "xine-lib/src/demuxers/demux_mpgaudio.c" In the cvs repository, the bug was introduced in the massive update from rev 1.141 to rev 1.142. If I save demux_mpgaudio.c from rev 1.141 into my sources for xine-lib 1.1.1 or 1.1.7 and 'make && make install', I then have a xine-lib that doesn't exhibit this bug. I am currently running xine-lib 1.1.7 (un-?)patched in this way. Obviously this isn't the ideal solution, as all of the updates to the file in the past 2 years are lost to me. Furthermore, I can't be the only one experiencing this problem, so there's a bug in there and it should be found and fixed. I've spent way too many hours trying to track down the bug in demux_mpgaudio.c, but the changes are big and way over my head, so I'm stuck. I'm running Gentoo Linux in 64-bit mode on a dual-core Athlon 64. Everything's up to date. I'd be happy to email one of the mp3's that exhibit this problem to any developer that wants to help me solve this problem, but they're all copyrighted by record companies, so obviously I can't upload one here. I'm happy to help in whatever way I can, but I'm at a loss for figuring it out myself at this point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1790087&group_id=9655 |
From: SourceForge.net <no...@so...> - 2007-09-07 16:16:47
|
Bugs item #1790087, was opened at 2007-09-07 13:48 Message generated for change (Comment added) made by dsalt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1790087&group_id=9655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: demuxer (stream type support) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Barber (josiah_barber) Assigned to: Nobody/Anonymous (nobody) Summary: Some MP3's lose first 2 seconds (approx) Initial Comment: Some of my mp3's start playing about 2 seconds into the song. Most mp3's are fine, but I have several in my collection that this happens with. All other mp3 players I have play the files correctly. I narrowed it down to xine-lib-1.1.0 being the last working version of xine-lib. Versions 1.1.1 through 1.1.7 all exhibit the bug. I narrowed it down further to the file "xine-lib/src/demuxers/demux_mpgaudio.c" In the cvs repository, the bug was introduced in the massive update from rev 1.141 to rev 1.142. If I save demux_mpgaudio.c from rev 1.141 into my sources for xine-lib 1.1.1 or 1.1.7 and 'make && make install', I then have a xine-lib that doesn't exhibit this bug. I am currently running xine-lib 1.1.7 (un-?)patched in this way. Obviously this isn't the ideal solution, as all of the updates to the file in the past 2 years are lost to me. Furthermore, I can't be the only one experiencing this problem, so there's a bug in there and it should be found and fixed. I've spent way too many hours trying to track down the bug in demux_mpgaudio.c, but the changes are big and way over my head, so I'm stuck. I'm running Gentoo Linux in 64-bit mode on a dual-core Athlon 64. Everything's up to date. I'd be happy to email one of the mp3's that exhibit this problem to any developer that wants to help me solve this problem, but they're all copyrighted by record companies, so obviously I can't upload one here. I'm happy to help in whatever way I can, but I'm at a loss for figuring it out myself at this point. ---------------------------------------------------------------------- >Comment By: Darren Salt (dsalt) Date: 2007-09-07 17:16 Message: Logged In: YES user_id=294680 Originator: NO That'll be this changeset: http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=0f6618441605;style=gitweb ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1790087&group_id=9655 |
From: SourceForge.net <no...@so...> - 2007-09-11 05:52:23
|
Bugs item #1790087, was opened at 2007-09-07 07:48 Message generated for change (Comment added) made by josiah_barber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1790087&group_id=9655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: demuxer (stream type support) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Barber (josiah_barber) Assigned to: Nobody/Anonymous (nobody) Summary: Some MP3's lose first 2 seconds (approx) Initial Comment: Some of my mp3's start playing about 2 seconds into the song. Most mp3's are fine, but I have several in my collection that this happens with. All other mp3 players I have play the files correctly. I narrowed it down to xine-lib-1.1.0 being the last working version of xine-lib. Versions 1.1.1 through 1.1.7 all exhibit the bug. I narrowed it down further to the file "xine-lib/src/demuxers/demux_mpgaudio.c" In the cvs repository, the bug was introduced in the massive update from rev 1.141 to rev 1.142. If I save demux_mpgaudio.c from rev 1.141 into my sources for xine-lib 1.1.1 or 1.1.7 and 'make && make install', I then have a xine-lib that doesn't exhibit this bug. I am currently running xine-lib 1.1.7 (un-?)patched in this way. Obviously this isn't the ideal solution, as all of the updates to the file in the past 2 years are lost to me. Furthermore, I can't be the only one experiencing this problem, so there's a bug in there and it should be found and fixed. I've spent way too many hours trying to track down the bug in demux_mpgaudio.c, but the changes are big and way over my head, so I'm stuck. I'm running Gentoo Linux in 64-bit mode on a dual-core Athlon 64. Everything's up to date. I'd be happy to email one of the mp3's that exhibit this problem to any developer that wants to help me solve this problem, but they're all copyrighted by record companies, so obviously I can't upload one here. I'm happy to help in whatever way I can, but I'm at a loss for figuring it out myself at this point. ---------------------------------------------------------------------- >Comment By: Josiah Barber (josiah_barber) Date: 2007-09-11 00:52 Message: Logged In: YES user_id=290408 Originator: YES I seem to have reduced the differences between the working and non-working version to it's simplest form, and am attaching it as a patch against the 1.1.7 version of src/demuxers/demux_mpgaudio.c. I'd like to add the disclaimer that I don't really know what I'm doing here: If the patch file is strange, I apologize, and in any case someone who actually understands the code should definitely look at it and make sure it makes sense. Specifically, the samplerate member of the mpg_audio_frame_t structure is of type int in my patch. For consistency, it should probably be of type uint16_t, or uint32_t, but I have no basis with which to decide which. Essentially, the fix is to add back in about 15 lines of code that were removed from parse_xing_header() during the update in question, with the code updated as necessary to work with the current code. With the patch, this bug is now fixed on my system, and xine seems to work normally with every file I've tested it with. Keep in mind I don't understand what this code does at all. File Added: demux_mpgaudio.c.patch-1.1.7 ---------------------------------------------------------------------- Comment By: Darren Salt (dsalt) Date: 2007-09-07 11:16 Message: Logged In: YES user_id=294680 Originator: NO That'll be this changeset: http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=0f6618441605;style=gitweb ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1790087&group_id=9655 |
From: SourceForge.net <no...@so...> - 2007-09-11 10:52:24
|
Bugs item #1790087, was opened at 2007-09-07 07:48 Message generated for change (Comment added) made by josiah_barber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1790087&group_id=9655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: demuxer (stream type support) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Barber (josiah_barber) Assigned to: Nobody/Anonymous (nobody) Summary: Some MP3's lose first 2 seconds (approx) Initial Comment: Some of my mp3's start playing about 2 seconds into the song. Most mp3's are fine, but I have several in my collection that this happens with. All other mp3 players I have play the files correctly. I narrowed it down to xine-lib-1.1.0 being the last working version of xine-lib. Versions 1.1.1 through 1.1.7 all exhibit the bug. I narrowed it down further to the file "xine-lib/src/demuxers/demux_mpgaudio.c" In the cvs repository, the bug was introduced in the massive update from rev 1.141 to rev 1.142. If I save demux_mpgaudio.c from rev 1.141 into my sources for xine-lib 1.1.1 or 1.1.7 and 'make && make install', I then have a xine-lib that doesn't exhibit this bug. I am currently running xine-lib 1.1.7 (un-?)patched in this way. Obviously this isn't the ideal solution, as all of the updates to the file in the past 2 years are lost to me. Furthermore, I can't be the only one experiencing this problem, so there's a bug in there and it should be found and fixed. I've spent way too many hours trying to track down the bug in demux_mpgaudio.c, but the changes are big and way over my head, so I'm stuck. I'm running Gentoo Linux in 64-bit mode on a dual-core Athlon 64. Everything's up to date. I'd be happy to email one of the mp3's that exhibit this problem to any developer that wants to help me solve this problem, but they're all copyrighted by record companies, so obviously I can't upload one here. I'm happy to help in whatever way I can, but I'm at a loss for figuring it out myself at this point. ---------------------------------------------------------------------- >Comment By: Josiah Barber (josiah_barber) Date: 2007-09-11 05:52 Message: Logged In: YES user_id=290408 Originator: YES Well, turns out I didn't test that patch well enough -- seeking within a file is broken in the files that were exhibiting the original bug, and the current time within any file is no longer updated in any gui clients. So, the hunt is back on. ---------------------------------------------------------------------- Comment By: Josiah Barber (josiah_barber) Date: 2007-09-11 00:52 Message: Logged In: YES user_id=290408 Originator: YES I seem to have reduced the differences between the working and non-working version to it's simplest form, and am attaching it as a patch against the 1.1.7 version of src/demuxers/demux_mpgaudio.c. I'd like to add the disclaimer that I don't really know what I'm doing here: If the patch file is strange, I apologize, and in any case someone who actually understands the code should definitely look at it and make sure it makes sense. Specifically, the samplerate member of the mpg_audio_frame_t structure is of type int in my patch. For consistency, it should probably be of type uint16_t, or uint32_t, but I have no basis with which to decide which. Essentially, the fix is to add back in about 15 lines of code that were removed from parse_xing_header() during the update in question, with the code updated as necessary to work with the current code. With the patch, this bug is now fixed on my system, and xine seems to work normally with every file I've tested it with. Keep in mind I don't understand what this code does at all. File Added: demux_mpgaudio.c.patch-1.1.7 ---------------------------------------------------------------------- Comment By: Darren Salt (dsalt) Date: 2007-09-07 11:16 Message: Logged In: YES user_id=294680 Originator: NO That'll be this changeset: http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=0f6618441605;style=gitweb ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1790087&group_id=9655 |