Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

increase max_syncs to 1500 #376

Merged
merged 1 commit into from Mar 14, 2019
Merged

increase max_syncs to 1500 #376

merged 1 commit into from Mar 14, 2019

Conversation

@halaei
Copy link
Contributor

halaei commented Mar 4, 2019

I have absolutely no idea about the meaning of the number, but I have an mp3 file which can only be read if max_syncs >= 1002. The file can be played by many players.

@lazka

This comment has been minimized.

Copy link
Member

lazka commented Mar 4, 2019

OK, why not. I'll have a look first as to why it needs that many in this case.

@halaei

This comment has been minimized.

Copy link
Contributor Author

halaei commented Mar 5, 2019

@lazka This commit in ffmpeg might have some relevant information for you:
FFmpeg/FFmpeg@2b3e9bb

I think my PR still doesn't work for some files. Maybe the numbers must be higher.

@halaei

This comment has been minimized.

Copy link
Contributor Author

halaei commented Mar 5, 2019

mpg123 also attempts to skip at least 64KB of junk data by scanning for headers.

@lazka

This comment has been minimized.

Copy link
Member

lazka commented Mar 5, 2019

Thanks, the max amount to skip is max_read which is already at 1024K. The syncs is the amount of mpeg headers markers found without a valid header following.

@lazka

This comment has been minimized.

Copy link
Member

lazka commented Mar 12, 2019

These files just look semi broken to me and mpg123 also does lots of one byte reads until it finds the header.

@halaei can you increase max_syncs to 1500 so it works with the second file as well.

@halaei

This comment has been minimized.

Copy link
Contributor Author

halaei commented Mar 13, 2019

Sure. I also have a couple of other files readable by ffmpeg but not mutagen. I can try to find what the number really should be in a day or 2 if that's ok to you.

@lazka

This comment has been minimized.

Copy link
Member

lazka commented Mar 13, 2019

Sounds good, thanks.

@halaei halaei force-pushed the halaei:increase-max-sync branch from 9d6db29 to 24f4f1a Mar 14, 2019
@halaei

This comment has been minimized.

Copy link
Contributor Author

halaei commented Mar 14, 2019

@lazka I force pushed 1500. However, there are some files that are still not processable and increasing the numbers won't help. Maybe the files are not really MP3, I don't know.

@lazka

This comment has been minimized.

Copy link
Member

lazka commented Mar 14, 2019

I like broken files -> reiter.christoph@gmail.com

@lazka

This comment has been minimized.

Copy link
Member

lazka commented Mar 14, 2019

@halaei thanks!

@lazka lazka merged commit dd36e9f into quodlibet:master Mar 14, 2019
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
quodlibet.mutagen #20190314.1 succeeded
Details
@lazka lazka changed the title increase max_syncs to 1024 increase max_syncs to 1500 Mar 14, 2019
@lazka

This comment has been minimized.

Copy link
Member

lazka commented Mar 16, 2019

Two files have lots of garbage between the id3 tag and the first mpeg frame. some players don't give up, mpg123 errors out for example.

One file is a ASF file (WMA) with a leading ID3 tag, which isn't something I have seen before.

I'll keep them around, but I'm currently tending to just label them as too broken.

@halaei

This comment has been minimized.

Copy link
Contributor Author

halaei commented Mar 16, 2019

Fine. Thanks for your time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.