Music Playing Problem - Skipping Track Endings, Missing Player Controls

[martinix 2]

Hi,

 

I'm not sure if this is a known problem or if it has been experienced by anyone else? The problem I'm experiencing is the intermittent cutting out and skipping of the last few seconds of a  music track when playing on Kodi using Emby. If you choose to play an album then, randomly, when playing the last few seconds of music of a track are skipped and the player jumps to the next track. I've done a clean install and checked using a number of configurations and the problem is reproduced. I've noticed the following:

 

1. The problem doesn't occur when playing with a 'standard' Kodi configuration using an SMB source and connection for the Music store on the file server.
2. The problem doesn't occur when using EmbyCon
3. When using the Emby plugin, the Fast Foward/Skip Forward and Fast Back/Skip Back controls are missing on the Full Screen Player view but do show on the Home Screen mini-player (Confluence Skin) on the Estuary Skin the FF/FR controls are missing.
4. Problem is not to do with player Cross Fading setting.
5. Sometimes a track will play to the end and sometimes the same track will cut out a few seconds before the end and jump to the next track.

 

Configuration is: Emby Server 4.2.1.0 Emby Kodi Plug-In 4.1.14

 

Log File - https://paste.kodi.tv/oqigeyovel

 

Would welcome any suggestions about how to fix problem.

 

Many thanks,

 

-martinix

[Angelblue05 4131]

Hmm, can you enable Kodi debug this one time and provide an updated Kodi log of the issue? Let me know the song title as well.

Edited September 2, 2019 by Angelblue05

[martinix 2]

Hi,

 

Here's an updated log file with debugging enabled. ( https://paste.kodi.tv/vunubicani ) There are three early track jumps in this example. They occur roughly 4 minutes after the start of each track.

 

The Album being played was: Martyn Bennett

 

1st track - Swallowtail

2nd track - Erin

3rd track - Cuillin pt 1

4th track - Cuillin pt 2

 

I'm wondering if this might be some kind of network buffering problem? I have one Kodi Windows client that connects by WiFi and one Kodi Windows client that connects by a wired network connection to the Emby server. The random track switches seem to occur with higher frequency on the WiFi connected client than on the wired connected client. I'll do some more comparisons and see if I can find out any more.

 

Hope this helps.

 

Thanks.

[martinix 2]

Hi,

 

Here's another example. Same Album. This time played from a client with a wired connection to the Emby server. Logfile: https://paste.kodi.tv/nevesodibi

 

Track               Length      Jump

1. Swallowtail    5.00       4.38

2. Erin              6.22        5.11

3 Cuillin Pt1      6.34        6.22

4. Cuillin Pt2     3.06        (played whole track)

[martinix 2]

Hi - I haven't got any further chasing down this problem. Just wondering if anyone else has/is experiencing a similar problem? If so any info. would be useful as it may help in  locating the problem. It is affecting both wired and wireless connected Kodi clients. Video content seems to play fine. - Many thanks.

[Angelblue05 4131]

@@Luke

 

Are you aware of music being cut short when played via the server? It is currently using the /emby/Audio/Id/stream.ext. If you tell me this issue wouldn't happen with universal music playback, I will make the switch.

[Luke 38498]

@@Luke

 

Are you aware of music being cut short when played via the server? It is currently using the /emby/Audio/Id/stream.ext. If you tell me this issue wouldn't happen with universal music playback, I will make the switch.

 

It shouldn't happen with either. Try downloading the contents of that url. If it returns the full file, then the problem is client-side.

[Angelblue05 4131]

@@martinix

 

Grab the file using this

http://{emby-server}/emby/Audio/28418/stream.mp3?api_key={emby-token}

Replace the brackets with valid information. If you are unsure, disable mask sensitive information in the add-on settings > advanced to see the full url in your Kodi log.

 

Let me know if the file is complete then or not.

Edited September 11, 2019 by Angelblue05

[Saviq 22]

I'm having the same issue here, and can confirm the complete file is downloaded.

 

When the interruption happens, the logs show:

2019-09-12 08:50:13.228 T:3130925952  NOTICE: EMBY.hooks.monitor -> -->[ q:monitor/ReportProgressRequested ]
2019-09-12 08:51:37.716 T:2810471296  NOTICE: Previous line repeats 16 times.
2019-09-12 08:51:37.716 T:2810471296   ERROR: CCurlFile::FillBuffer - Failed: Transferred a partial file(18)
2019-09-12 08:51:37.716 T:2810471296 WARNING: CCurlFile::FillBuffer - Reconnect, (re)try 1
2019-09-12 08:51:37.999 T:2810471296   ERROR: CCurlFile::FillBuffer - Failed: Requested range was not delivered by the server(33)
# here it starts playing the next song
2019-09-12 08:54:22.287 T:3178980224  NOTICE: Previous line repeats 32 times.
2019-09-12 08:54:22.287 T:3178980224 WARNING: <[ webservice/3726263880/0 ]
2019-09-12 08:54:22.292 T:2810471296  NOTICE: EMBY.hooks.webservice -> path: https://media.server.net:443/emby/Audio/203819/stream.flac?api_key={emby-token}

Edited September 12, 2019 by Saviq

[Saviq 22]

I think the problem is that the streaming url does not respect ranges:

curl --output file.flac --range 25000000-30000000 https://media.server.net:443/emby/Audio/203817/stream.flac\?api_key\={emby-token}
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.6M    0 57.6M    0     0  12.7M      0 --:--:--  0:00:04 --:--:-- 13.5M

> GET /emby/Audio/203817/stream.flac?api_key={emby-token} HTTP/1.1
> Host: media.server.net
> Range: bytes=25000000-30000000
> User-Agent: curl/7.64.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Access-Control-Allow-Headers: Accept, Accept-Language, Authorization, Cache-Control, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-MD5, Content-Range, Content-Type, Date, Host, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, Origin, OriginToken, Pragma, Range, Slug, Transfer-Encoding, Want-Digest, X-MediaBrowser-Token, X-Emby-Token, X-Emby-Authorization
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
< Access-Control-Allow-Origin: *
< Server: UPnP/1.0 DLNADOC/1.50
< Content-Type: audio/flac
< Accept-Ranges: none
< Date: Thu, 12 Sep 2019 07:04:10 GMT
< Transfer-Encoding: Chunked
< Strict-Transport-Security: max-age=16000000; includeSubDomains; preload;
<
{ [14695 bytes data]
* Connection #0 to host media.server.net left intact

Even though I only requested 5miB, I got the full 57MB.

 

It doesn't happen if requesting the playback from Emby into Kodi, the stream URL is passed verbatim to Kodi's player, which seems to be more robust than proxying through the plugin-internal web service.

Edited September 12, 2019 by Saviq

[martinix 2]

Hi,

 

Just a quick follow up. I did find an old thread in the Kodi forums which reported a similar problem..  https://forum.kodi.tv/showthread.php?tid=205130 . I tried the Registry Edit in the referenced article .. https://social.technet.microsoft.com/Forums/en-US/b03d318f-fb37-4426-bdda-4046550edc0d/windows-81-pro-smb-sharing-problem?forum=w8itpronetworking . Setting the IRPStackSize to 50 does seem to have removed the problem of skipping. Whether or not it is just masking the effect of an underlying problem I don't know. I'll give an update when I have more info. and I'll try the suggestions above.

 

Re: Fast Forward/Fast Rewind controls with the Kodi Confluence Skin on the Home Screen the player controls show and operate correctly. When in Full Screen mode the controls are greyed out. With the default Estuary Skin the controls don't show.

 

Thanks.

[martinix 2]

Hi - just to report that the change to registry IRPStackSize above didn't fix the problem. The jumps seemed to occur less frequently but still happened. I'll do the other tests suggested above and report - thanks.

[Saviq 22]

FWIW there's no Windows involved on my side and the issue is there, so doubt this relates.

[Angelblue05 4131]

Yeah the issue is we can't change not routing via the internal web service, because the music database does not behave correctly when parameters are added to the url, such as the now required api key. This was the solution to work around this issue...

[martinix 2]

Ok. Many thanks for your advice. Based on the above, my understanding is that there isn't any workaround for this problem at present? Do you think it might be possible in the future?

[Angelblue05 4131]

I’m still looking into a possible solution. I will keep you guys posted if I have something to test.

Edited September 14, 2019 by Angelblue05

[martinix 2]

many thanks. I know this is difficult stuff. much appreciated.

[vferg 7]

Just posting to state that I have this same issue as well. Think it's been happening for a bit now but I thought it was a Kodi issue. After seeing this thread I can say this is exactly the same issue I am having. Thanks

[jmangan 11]

I've just found that I have the same problem. I'm trying to listen to 'War of the Worlds' and after ~5+ minutes it just skips to the next track.

 

First track or two I thought maybe something odd with the files - but not ALL of them.

 

Emby on CentOS, Kodi on Pi - all up to date. Not using SMB.

 

 

This may be completely unrelated but I recently found that several double albums appeared in my library but didn't actually have any albums or tracks to play.

I copied the tracks off, deleted the album through the console, copied the same data back and scanned the library. All good!

 

I hope some of that helps.

[jmangan 11]

Further, I played the same tracks through the browser on Windows 10 without issue so it's not an issue with the tracks or Emby as such but Kodi/Emby Add-On.

[TeamB 2384]

Try native playback mode.

 

Try EmbyCon just to test if this addon has the same problem, this will further narrow down your issue to either an addon issue or a Kofi issue.

[Saviq 22]

I believe I already dug deep enough above in posts #9 and #10 - if the stream is interrupted for whatever reason, the Emby for Kodi plugin fails to resume because it can't get the requested byte range from Emby.

[Luke 38498]

I think the problem is that the streaming url does not respect ranges:

curl --output file.flac --range 25000000-30000000 https://media.server.net:443/emby/Audio/203817/stream.flac\?api_key\={emby-token}
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.6M    0 57.6M    0     0  12.7M      0 --:--:--  0:00:04 --:--:-- 13.5M

> GET /emby/Audio/203817/stream.flac?api_key={emby-token} HTTP/1.1
> Host: media.server.net
> Range: bytes=25000000-30000000
> User-Agent: curl/7.64.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Access-Control-Allow-Headers: Accept, Accept-Language, Authorization, Cache-Control, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-MD5, Content-Range, Content-Type, Date, Host, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, Origin, OriginToken, Pragma, Range, Slug, Transfer-Encoding, Want-Digest, X-MediaBrowser-Token, X-Emby-Token, X-Emby-Authorization
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
< Access-Control-Allow-Origin: *
< Server: UPnP/1.0 DLNADOC/1.50
< Content-Type: audio/flac
< Accept-Ranges: none
< Date: Thu, 12 Sep 2019 07:04:10 GMT
< Transfer-Encoding: Chunked
< Strict-Transport-Security: max-age=16000000; includeSubDomains; preload;
<
{ [14695 bytes data]
* Connection #0 to host media.server.net left intact

Even though I only requested 5miB, I got the full 57MB.

 

It doesn't happen if requesting the playback from Emby into Kodi, the stream URL is passed verbatim to Kodi's player, which seems to be more robust than proxying through the plugin-internal web service.

 

This is because it is requesting a transcoding url where byte range requests are not supported. You could try instead:

https://media.server.net:443/emby/Audio/203817/stream?api_key\={emby-token}&static=true

This get the original audio without any transcoding, and byte range requests will be supported.

[martinix 2]

This is because it is requesting a transcoding url where byte range requests are not supported. You could try instead:

https://media.server.net:443/emby/Audio/203817/stream?api_key\={emby-token}&static=true

This get the original audio without any transcoding, and byte range requests will be supported.

 

does this suggestion provide the basis for a possible fix? if so, what would we need to do/change to test it out? Thanks.

[Luke 38498]

I think the audio url will need to be adjusted. Is this EmbyCon or Emby for Kodi?