Hi
When I start playback of an audio file through some remote, e.g. yatse (e.g. file mode), it begins playing for a split second, then restarts after a short dropout.
–> This does not happen when I browse through the kodi gui (using a keyboard of yatse’s arrow keys) and start playback this way.
–> If this happens, playback will also not be gapless (as if playback was started an extra time at the beginning of a new track).
I think this is a serious issue, really degrading audio playback. I has been around since the Leya alphas, in
libreelec 8.2.5 (kodi 17.6) it was not there yet.
Logs:
Case 1: start playback through file mode in yatse (problem shows up)
https://pastebin.com/mnLT0Fkb
Case 2: start playback browsing through kodi gui (problem does not show up)
https://pastebin.com/jN9Dk9KP
Running libreelec 9.2 (kodi 18.5) on a Raspberry Pi 3 model B+. However, I can also reproduce this on a Nvidia Shield running kodi 18 for android, and apparently it’s also happening on Windows. It also happens using OSMC.
This is not yatse-specific, it also happens in kore or using the web browser interface.
Any ideas how to get to the bottom of this? :-)
I have not been able to reproduce this immediately, and if it were a common issue I'm sure there would be a lot more complianed before now. So it is something more system specific
You have tried a variety of platforms but presumably every time the music files in the same location on a NAS drive (guessing from the path name) connected using Samba? Can you try with music loacted somewher else, using NFS or locally? Does this only effect file view, or if you create a music library and play from there does it do the same double start?
I have to say my immediate suspicions are Samba related, but that is just first guess
Hi Dave
Well, it happens on the identical file. The difference is how playback is started (or how the playlist is created), not where the file is.
Nevertheless, I also tested this with a file on a usb stick or locally on the rpi's sd card. The result is always the same.
Actually I think you should be able to reproduce it easily. Of course you will need a file that has high volume right at the start. With a file that has silence for the first ~1 s you won't notice.
You can e.g. connect a web browser interface and then start playback through the kodi interface. The playlist should show up on the browser.
Then you can queue the same file in the files section using the browser, so it will show up at the end in the playlist.
Now you can play the same file, appearing twice in the playlist (maybe stop playback in between). The first one will play correctly, the second one will give a dropout at the beginning.
And yes, this sounds crazy, the file is identical, the only difference is how it was added to the playlist, still playback is different. But I can reproduce this as many times as I want. I'll make you a video if you like.;-)
Cheers
Oliver
(2019-12-09, 15:05)lich000king Wrote: [ -> ]Nevertheless, I also tested this with a file on a usb stick or locally on the rpi's sd card. The result is always the same.
Humm... OK, most odd for local music.
(2019-12-09, 15:05)lich000king Wrote: [ -> ]Actually I think you should be able to reproduce it easily. Of course you will need a file that has high volume right at the start. With a file that has silence for the first ~1 s you won't notice.
I will edit a music file to be immediately loud and try that, or perhaps I misunderstand you, but no I have not been able to reproduce this. No need for a video report just yet.
Just to confirm how to recreate issue: add music to the queue using GUI, and append a file using a JSON app like Chorus. When playback reaches the music added via JSON API it will "start twice" (play briefly, dropout and restart).
Do you have a music library? If so then does this also happen when adding songs from the library to the queue using GUI/JSON, or only when handling music files? Are those files also in the library?
(2019-12-09, 17:42)DaveBlake Wrote: [ -> ]I will edit a music file to be immediately loud and try that, or perhaps I misunderstand you, but no I have not been able to reproduce this. No need for a video report just yet.
Just use e.g. this test file:
https://sample-videos.com/audio/mp3/wave.mp3
With this it will be very obvious if it's 'started twice' or not.
To reproduce add the file to playlist using GUI. --> item #1 in playlist
Then add it to playlist using json. --> item #2 in playlist.
Now if you play item #1 it will start playing as it should.
If you start playback of item #2 it will start twice.
You can repeat this as many times as you like.
You had better provide that video @
lich000king because I really can not reproduce what you describe. I have listened to waves alot trying various combinations of ways of starting playback/adding to queue etc. , I don't get any "double start". Likewise testing with tracks, queued separately as you describe, from an album were any lack of gapless playback would be glaringly obvious.
Preferably show the issue using web interface Chorus (for removal of involvement of other apps etc. ).
It could also would help if you answered my questions about your music library.
* Do you have a music library?
* If so then does this also happen when adding songs from the library to the queue using GUI/JSON, or only when handling music files?
* When it happens in file view are those files also in the library?
In your first post you said "and apparently it’s also happening on Windows". Does this mean you have experienced the issue on Windows, or are you inferring from something else, and if something else then what? I am testing with Windows, could it be that platform does not exhibit the problem?
Hi again
Ok, so here ist the vid:
https://mega.nz/#!MgwCSQDS!HV4mRJXJdiOZa...XI_0TIq_qo
I am now testing this on a virgin installation of Libreelec 9.2.0, no addons, no setting changes no nothing. Did not even turn off system sounds;-)
The sample file from above I copied into a directory "test" on the /storage partition on the sd (--> no USB, no ethernet, no samba...)
I am exclusively using Chorus 2 to operate Kodi. What I do is the following:
- use the remote in Chorus to browse to the file in the GUI and queue it (first part of the vid)
- use the browser in Chorus to add the same file to the queue
- start playing the two items a few times by clicking on them on the playlist in chorus.
The 'problem' should be rather obvious now:
- The first item in the playlist stars once and plays without dropout.
- The second item starts a second time after a short dropout.
Note (this surprises me somewhat): when the playback of the first item finishes and the second item starts playing because it is next in the queue (rather than because I click on it), there is no dropout. This happens in the video before I start clicking on the playlist items (and is reproducible).
I'm not using a library usually. However I am going to test this now and report back.
Allright, I created a library and made few tests. I could not reproduce the issue here, i.e. no dropouts when starting playback using the library either through chorus or yatse. I'm a bit confused since I remember having this also with earlier tests using the library. Maybe I was wrong.
Let's hope this helps getting to the bottom of this.:-)
Thanks for the video, I was not quite doing the same in my testing, I was more focussed on gapless playback with flow from track to track rather than clicking to start playback. Unfortunately following your steps exactly I still can't reproduce the dropout on Windows. I will try later to set up LibreElec and test there too.
If it only happens from file view mode, and for files that are not in the library then that may be a clue. When starting playback of a file Kodi will be attempting to fetch additional information for the track as it starts, this will be unsuccessful and take longer for non-library items and I guess could be delaying the audio for you for some reason. But unless I can reproduce I am just guessing in the dark.
Quote:When starting playback of a file Kodi will be attempting to fetch additional information for the track as it starts, this will be unsuccessful and take longer for non-library items and I guess could be delaying the audio for you for some reason.
That sounds like a very reasonable guess, though. Do you happen to know where in the kodi source this fetching happens?
If it's easy to just turn that off, I can test if the dropouts disappear. I can build libreelec from source.
Edit:
I made another quick test.
Indeed, once the file is in the library, there is no dropout even when started in file mode.
When I remove the source from the library and clear the library in the settings, the dropouts are back.
(2019-12-20, 18:04)lich000king Wrote: [ -> ]Do you happen to know where in the kodi source this fetching happens?
If it's easy to just turn that off, I can test if the dropouts disappear. I can build libreelec from source.
If you want to poke about in the code then CMusicThumbLoader::FillLibraryArt is the method I have in mind - I would not remove it completely though.
Something to try would be not reading tags when in file view mode - no tags read, no db artist lookup etc. See the setting in Settings>media>music>files and disable. That should also remove the dropout, test it out please.
I want to reproduce (prefreably while in debugger) so I can see what is blocking the main thread and causing the drop out, just not managed that yet. Also I'm not sure how common it is to jump around items on the current queue via JSON, hence how much to expect this to have been spotted by other users or if something system specific is involved.
(2019-12-21, 20:02)DaveBlake Wrote: [ -> ]Something to try would be not reading tags when in file view mode - no tags read, no db artist lookup etc. See the setting in Settings>media>music>files and disable. That should also remove the dropout, test it out please.
This does not help. I.e. when I disable "Enable tag rading", or also "Search for thumbnails on remote shares", I still get the dropouts.
Quote:Also I'm not sure how common it is to jump around items on the current queue via JSON, hence how much to expect this to have been spotted by other users or if something system specific is involved.
Well, no need to jump around playlist items. Starting playback in file mode (when no library is present) will produce a dropout immediately.
(2019-12-22, 13:30)lich000king Wrote: [ -> ]This does not help. I.e. when I disable "Enable tag rading", or also "Search for thumbnails on remote shares", I still get the dropouts.
Humf... then it isn't the attempt to look up artist and fetch art that causes the drop out, no tag reading means no artist hance that processing does not occur. So I'm barking up the wrong tree.
(2019-12-22, 13:30)lich000king Wrote: [ -> ]Well, no need to jump around playlist items. Starting playback in file mode (when no library is present) will produce a dropout immediately.
Your video showed the dropout happening when you clicked on a 2nd item in queue to start playback (what I meant by "jump about"), but you said was OK when flows to next item itself. I'm still not reproducing the behaviour, which is very frustrating, but I will keep trying.
(2019-12-23, 16:59)DaveBlake Wrote: [ -> ]Your video showed the dropout happening when you clicked on a 2nd item in queue to start playback (what I meant by "jump about"), but you said was OK when flows to next item itself. I'm still not reproducing the behaviour, which is very frustrating, but I will keep trying.
That's true. The point of this was to demonstrate that it can be reproduced again and again. As you point out, when it transitions from the first to the second playlist item, there is no dropout. This is rather surprising to me.
If I just start playback from file view, (no prior playlist, not worrying about playlists at all) there will also be a dropout. This is how I generated the logs.
I'm really surprised you can't reproduce it. Do you have a Pi with libreelec on it?
Basically this should reproduce simply as follows:
- install libreelec 9.2 (write image on SD)
- copy the test file from above to the SD
- put it in a Pi (I'm using 3B+)
- start playback of the test file in file view (through chorus 2)
After no end of attempts to reproduce this with Chorus2, I decided to try just using JSON commands directly (from Postmaster), and at last managed to reproduce the repeated-start/dropout effect. That is a relief, and reproducable on my Windows dev env so I can debug. Can I stop listening to waves now, it is not chilling me out.
But odd that JSON directly gave me it when Chorus2 didn't. Anyway at least something I can dig into. Progress of a sort.