-
-
Notifications
You must be signed in to change notification settings - Fork 107
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
Playback ends abruptly before the end of tracks #452
Comments
hm strange. i use airsonic-refix with gonic every day. do you have transcoding rules setup? any is there anything in the gonic logs when this happens? |
Indeed, I use Maybe I should cross-post the issue at airsonix-refix... |
could you leave the refix dev tools (F12) open and wait for the error to happen again? see if there are an errors in the Console tab |
Sure, will do. I cannot consistently reproduce the bug, so it might take a while before I get back to you :-) |
I just got it after playing 4 tracks. Here are the logs -- nothing interesting (except maybe for the empty Error box on refix side): It seems the problem lies with the track length. The playback seems OK, as it goes to the "end" of the track. But the track length was "miscalculated" and shorter than in reality. Does that make sense? |
hm. can you try a different codec? like opus_128? (much better codec anyway :D smaller files with greater fidelity) to see if the issue is with mp3 |
I went with |
@sentriz I wonder if a debug option to additionally route the transcoder output to a file in /tmp might help determine where the issue lies. |
@brian-doherty oh good point, the caching transcoder does this by default @khannurien maybe you could run ffprobe (from ffmpeg) on the most recent files in your gonic audio cache path? find the track that had the error and see what ffprobe says |
Here it is:
The duration (said to be estimated from bitrate) is on point. |
Sounds like the bug is in airsonic-revix then. BUT it might be nice for Gonic to populate the MP3 LENGTH tag by adding "-metadata:t=length x:xx" when transcoding to MP3. |
@brian-doherty i assume that would need to be a 2 stage encode then? since gonic streams the ffmpeg output in real time, and ffmpeg wont know the real duration until it's finished encoding i also wonder why the bitrate is inacurate in the first place, since mp3 320 is fixed bitrate |
If you're feeding it the length yourself, then I don't think so, but I haven't tried it. |
oh right, but i mean how would gonic get the length itself? if not with bitrate estimation |
In populateTrack you're pulling it from the tagReader and storing it in the DB, so you can just use that if non-zero, and omit if not. That's the best you can do until you calculate the length from the data as per the comment in populateTrack. |
I wonder if the file being transcoded lacks the length in the tags and so that's why ffmpeg can't copy it over? In which case following that comment and using FFMpeg to provide the length and bitrate at scan time might be the answer to the whole issue. UPDATE: You would have to do both, actually. |
yeah exactly the length isn't present in the tags at all, that's why ffprobe and refix had to resort to bitrate estimation. so ah. ofc bitrate estimation could be way off when the file has a large embeddded artwork or something |
@khannurien What is the ffprobe output for the original track in question? |
@sentriz here it is:
|
@khannurien @sentriz Interesting -- duration is in the tags. I guess FFMpeg isn't trusting it or something? |
that is mighty strange |
@brian-doherty @sentriz I'm really not familiar with this stuff, correct me if I'm wrong -- the |
I wonder how airsonic-advanced handles that quirk. I just remembered I had a somewhat similar problem there a few years ago: airsonic/airsonic#1343 It seems that it has been fixed in the meantime though, as it does not occur when I use airsonic-advanced rather than gonic as a backend. |
Looks like the LENGTH tag in MP3 exists but no one populates or reads it. Might just be best to let this dog lie and submit the bug to airsonic-refix. |
sounds good. thanks for you help @brian-doherty @khannurien ! |
Just in case someone stumbles upon this issue looking for a solution: it most probably is a transcoding-related bug. The easiest way to solve it has been to switch from mp3 to opus transcoding profile in gonic's admin. |
Damn it. Just as I typed this comment, the issue happened again. Here is the ffprobe output for the file:
In airsonic-refix player, I saw the track length set at 4:34 (while it is 6:16 in reality, as stated by ffprobe). Playback stopped after 4:34 and skipped to the next track. |
that's weird. where did 4:34 come from i wonder? it seems ffprobe says the duration is 06:16 both by the file itself and the metadata @khannurien can you email me that dde0263254984adb7c723a7f3e85b001 file? and maybe the original too? email is on my profile |
Done. Maybe this is not a transcoding problem after all... |
@khannurien can't reproduce it unfortunately. which browser are you running? |
Firefox 121 |
Hello, I have the exact same issue as the one mentioned above, using the same setup of:
Will update if I find more relevant information or a stable reproducible case! |
gonic version: v0.16.2
docker tag: sentriz/gonic:latest
When using airsonic-refix as a gonic client, I sometimes get abrupt playback stop before the end of tracks -- especially longer tracks (7 minutes and more).
I assume this is related to gonic, because this does not happen under airsonic-advanced with airsonic-refix as a client.
I wanted to open this issue so that more people can confirm if that happens for them too.
I'll be happy to share more details and help investigate further.
Thanks for the hard work,
Vincent
The text was updated successfully, but these errors were encountered: