lms
lms copied to clipboard
DSub shows incorrect long track time
I'm using the latest Docker image, and when streaming to DSub over Subsonic API, the lengths are properly shown in the album list, but upon playback are incorrect and often insanely long (58 minutes for ~6 minute track).
Analyzing the DSub streamed files shows incorrect bitrates, all of my files are V0 mp3. ffmpeg -i file
shows lower than actual bitrate and states Estimating duration from bitrate, this may be inaccurate
, perhaps it has to do with this.
Hi, Thanks for reporting this. Do you use transcoding?
No, I don't use transcoding.
Do you get the issue with another subsonic server?
Airsonic doesn't have the issue.
I do not reproduce the issue. I used ffmpeg with libmp3lame to create a v0 mp3 file. What I observe is that DSub is unable to scroll in the file as long as it is not completely downloaded (showing -:-- as duration). Once the download is complete replaying the song will show the correct duration and scrolling is enabled.
Edit: Android 8, DSub up to date with Google Play)
I am experiencing this issue with a lot of the tracks I have, I can send samples by email if you so wish.
I believe it may have to do with the fact that, despite having transcoding disabled, all tracks I stream to DSub get reencoded as mp3 and ffmpeg displays the length calculation warning with only the streamed files, not originals. I am supposing they are reencoded since the encoder tag is LAME on all originals but Lavf on streamed files.
Ok, it would be really helpful to have a sample!
My address is public on my profile, if you could email me I could provide you with samples. :)
Ok indeed I confirm the bug. TagLib incorrectly guesses the song duration, and that's what we report (using the Subsonic API but also to the web player)
Also, you might realize that the bitrates and encoder tags are different in the two, but I have transcoding disabled?
The problem is that we send the wrong duration, and DSub then uses this wrong information to display the track duration. Not sure about the file you sent. Maybe it is someway broken, I will investigate
I have noticed all DSub-streamed files appear with the same issue, different encoder and bitrate, and the server logs that it is transcoding, so I assume they are transcoded.
Should I report this as a seperate bug on the tracker?
No, this is actually the same root cause: TagLib is wrong on duration/bitrate
I see, thanks! :)
Unfortunately still not fixed in the newest taglib 1.12 (even scanning in accurate mode)
Still not fixed in taglib 1.13 (even scanning in accurate mode)
I think we should just make a issue at taglib, like we did for #359