Jump to content

Playback fails, shows logo


hootie318

Recommended Posts

flatline69

Just testing a few things there. Can you try this build?

 

Sure thing - soon as my kid and his friends release control of the TV ;)

Link to comment
Share on other sites

flatline69

OK installed 4.0.6e - it worked on the first title I tried (The 6th Day), second title I tried it did the skip-navigate-playback, third it did the right title, subsequent titles it failed to playback. Attaching log.

01_KODI.zip

  • Like 1
Link to comment
Share on other sites

flatline69

OK, installed 4.0.7a over top of stable and tested. It's only skipping 1 movie ahead now and I see the Emby loading video. I tested with directly trying to play "The 6th Day" which skipped 1 movie ahead in the list to "The 7th Voyage of Sinbad". When I first tried, it asked me to resume or start over; the interesting part the resume was -1 day, xxxx minutes in the dialog :) Was the only time I saw this during testing.

 

Anyways, I re-tested, this time is didn't ask to resume but skipped to "The 7th Voyage of Sinbad". So I thought, what if I go 1 movie ahead of the one I want to watch, sure enough, "The 6th Day" played.

 

Log attached.

 

EDIT: I should note, it's faster than before but compared to stable, it still takes a long time for a video to start. Direct play (SMB) is obviously fastest of all (for me anyways, it's almost instant.)

01_KODI.zip

Edited by flatline69
  • Like 1
Link to comment
Share on other sites

Angelblue05

I see what's happening in your log. I don't understand why it is happening though.

 

It's like, when we tell Kodi to play the movie it does, then boom, it almost instantly calls to start playback of the next title. Which is why maybe you think it's slower. Because it double loads the playlist for reason unknown at this moment.

 

You still have those bad requests on playback stopped.

Edited by Angelblue05
Link to comment
Share on other sites

Angelblue05

@@flatline69

 

I have another person testing CE for me and their setup does not behave the way your setup does.

 

They are using Kodi Leia 18.1

2019-02-20 22:54:02.250 T:4092121008  NOTICE: Kodi compiled 2019-02-19 by GCC 8.2.0 for Linux ARM 32-bit version 3.14.29 (200221)
2019-02-20 22:54:02.250 T:4092121008  NOTICE: Running on CoreELEC (official): 9.0-nightly_20190219, kernel: Linux ARM 64-bit version 3.14.29 aarch64

Can you try updating your setup to that version? It was compiled 3 days after yours. Or whatever is the latest now. You are still on Kodi 18.0 which had some playback bugs.

 

I see where things are going wrong. For some reason, when we start to play your movie, CE triggers playback stop (I'm sure it's for the emby-loading video, but it picks up the movie we are trying to play instead) and that's what is causing the behavior I'm seeing in your log where it skips ahead. Keep me posted

Edited by Angelblue05
Link to comment
Share on other sites

flatline69

@@flatline69

 

I have another person testing CE for me and their setup does not behave the way your setup does.

 

They are using Kodi Leia 18.1

2019-02-20 22:54:02.250 T:4092121008  NOTICE: Kodi compiled 2019-02-19 by GCC 8.2.0 for Linux ARM 32-bit version 3.14.29 (200221)
2019-02-20 22:54:02.250 T:4092121008  NOTICE: Running on CoreELEC (official): 9.0-nightly_20190219, kernel: Linux ARM 64-bit version 3.14.29 aarch64

Can you try updating your setup to that version? It was compiled 3 days after yours. Or whatever is the latest now. You are still on Kodi 18.0 which had some playback bugs.

 

I see where things are going wrong. For some reason, when we start to play your movie, CE triggers playback stop (I'm sure it's for the emby-loading video, but it picks up the movie we are trying to play instead) and that's what is causing the behavior I'm seeing in your log where it skips ahead. Keep me posted

 

OK, I'll update to a nightly build and re-test. Hopefully that one is still available. Is this build working correctly as per the tester?

  • Like 1
Link to comment
Share on other sites

flatline69

Yes, playback works as it should for him.

 

It looks like there was a new stable version (9.0.1). Try that first.

 

9.0.1 is labeled but doesn't appear available yet. I ended up installing 2-22 nightly and upgraded to 4.0.7a and playback works. Still a bit slow. Resume is broken though; it asked me twice for the same title (first was proper resume timestamp; then the loading image and another prompt for resume -1 day, 23:59:59) and then skipped ahead to the next title and started playing it.

 

EDIT: Corrected resume timestamp; missed "day"

01_KODI.zip

Edited by flatline69
  • Like 1
Link to comment
Share on other sites

Angelblue05

Yes this time I see it behave normally when we initiate playback. It no longer stops playback first.

 

With the next version, I'm going to add a clean up task to clear plugin paths from the database. That's is what is causing the double prompt. If you repair your library, it should correct that and stop double prompting you.

 

I'm still not sure for that resume value, it's strange for sure. I'll need to add additional logging for that one.

 

Edit: Still slow? It shows in your log the player opening the file to play within 3 seconds from the emby-loading video? I'd have to see a log with the before method (stable version) to compare, but I hardly call this slow considering the file is provided via Emby to Kodi? :)

Edited by Angelblue05
Link to comment
Share on other sites

flatline69

Yes this time I see it behave normally when we initiate playback. It no longer stops playback first.

 

With the next version, I'm going to add a clean up task to clear plugin paths from the database. That's is what is causing the double prompt. If you repair your library, it should correct that and stop double prompting you.

 

I'm still not sure for that resume value, it's strange for sure. I'll need to add additional logging for that one.

 

Interestingly enough - and I know I asked Fred about this way back; when selecting a title from "currently watching" from home screen, it's pretty darn fast, almost as fast a direct access. Seem to recall he said there was no difference from playback from that area vs inside a movie hub area (ie; I select ADULTS library, see all my posters, select title from there.)

 

I'll try a repair and see if that helps. Guessing the weird value is due to some calculation because of an already existing resume request? I'm guessing of course but seems to make sense to me.

  • Like 1
Link to comment
Share on other sites

flatline69

Edit: Still slow? It shows in your log the player opening the file to play within 3 seconds from the emby-loading video? I'd have to see a log with the before method (stable version) to compare, but I hardly call this slow considering the file is provided via Emby to Kodi? :)

 

The delay is visible; noticeable. It's nit-picky I know. Mainly because the delay has no feedback for the user. Under stable it has the spinner whereas in 4.0.7a there's nothing (looks like it froze/paused) and then the emby loading video. My LAN and my Kodi box (MECOOL KI PRO) are Gigabit. With direct access, there's no delay; screen goes black instantly and playback starts. I'm going to repair the library and re-test resume and then try to capture timings from "continue watching" vs hub/library/poster view.

 

EDIT: Stable build is roughly the same; I think it's the lack of user feedback that gives the impression of being slow. However, that being said, neither stable or beta in add-on mode are as fast as direct-access; the latter is easily milliseconds in time, can't even finish saying "one-Mississippi" before it's playing. Not scientific, I know, it's more a butt-dyno thing.

Edited by flatline69
  • Like 1
Link to comment
Share on other sites

Angelblue05

Yes well it's one of the issues we had with plugin paths. We needed to add the resume point twice in database (for different paths access widget and library) and I believe that's what is causing this issue now.

 

Plugin paths, even though they work, required a lot of messing around and behave quite differently from platform to platform. Especially with playback that initiates from widgets on the home screen.

 

With the new playback method, there is no longer a difference between playing from library or from the home screen widgets. No more workarounds for the resume point. No more artwork issues.

 

It shouldn't be slow though. I tested it on my old firetv stick and playback is faster than using plugin paths. If anything it should be even. For sure, if you use Direct play (not direct play over http), then it's almost as instant as native playback mode.

  • Like 1
Link to comment
Share on other sites

Angelblue05

The delay is visible; noticeable. It's nit-picky I know. Mainly because the delay has no feedback for the user. Under stable it has the spinner whereas in 4.0.7a there's nothing (looks like it froze/paused) and then the emby loading video. My LAN and my Kodi box (MECOOL KI PRO) are Gigabit. With direct access, there's no delay; screen goes black instantly and playback starts. I'm going to repair the library and re-test resume and then try to capture timings from "continue watching" vs hub/library/poster view.

 

EDIT: Stable build is roughly the same; I think it's the lack of user feedback that gives the impression of being slow. However, that being said, neither stable or beta in add-on mode are as fast as direct-access; the latter is easily milliseconds in time, can't even finish saying "one-Mississippi" before it's playing. Not scientific, I know, it's more a butt-dyno thing.

Understood. I think I can squeeze the busy dialog in there somewhere.

 

That's why Embuary is the skin to use :) It shows a nice loading circle in the corner, thanks to sualfred.

Link to comment
Share on other sites

flatline69

That's why Embuary is the skin to use :) It shows a nice loading circle in the corner, thanks to sualfred.

 

Are you talking about the green K top-right or the spinner top-left? If the latter, I only see that when the emby-loading video comes up. The green K only when updates are happening and not for playback. In stable, I see the green spinner right on the poster itself or from other playback view (ie; currently watching) center of screen.

Link to comment
Share on other sites

flatline69

Yes that's what I'm referring to. This way you know it's not frozen?

 

yeah I only see that when the emby-loading video shows but the "pause" is definitely a second/second-and-a-half before I see that. With stable, I saw the spinner on the poster/center of screen and then playback; gives the user the impression something is happening. I know, I know... it's a first-world problem where that sort of timing is something to complain about :) Always appreciate the work/help you give, just wanted to make sure that's said--don't want to seem ungrateful.

 

EDIT: Maybe add a third option, ie: Emby-Loading, Blank or a static image w/loading on it?

EDIT: A static image may be more suitable to low-powered devices; betting if I tossed Kodi on my laptop it wouldn't seem like a delay at all but entirely different beast. Although it's "unsupported"; my Android TV boxes have CE written directly to the internal flash (vs external USB/SDCARD as per recommendation) which is fast enough (for DB transactions, loading images, etc) but not the fastest and probably contributes to the delay perception. Images load faster than videos off the medium in this use-case. Just a rambling train of thought with my morning coffee while I wait for the repair to finish.

Edited by flatline69
  • Like 1
Link to comment
Share on other sites

Angelblue05

Ah yes I see what you mean. That I cannot fix. Do try to repair your library to rule out some weird Kodi interference with the first resume dialog or something. What is your default play action again?

2019-02-23 07:04:53.855 T:3268268912 WARNING: <[ webservice/3434667584/0 ]
2019-02-23 07:04:57.153 T:3268268912 WARNING: [ webservice/3643990304 ] path: /emby/kodi/movies/49549/file.strm?KodiId=5&Name=13+Assassins+%282010%29.mkv&Id=49549 params: {'KodiId': '5', 'Name': '13 Assassins (2010).mkv', 'Id': '49549'}

Weird because my CE tester has no such delays. For example

2019-02-20 22:56:13.144 T:3354391408 WARNING: <[ webservice/3412848768/0 ]
2019-02-20 22:56:13.166 T:3354391408 WARNING: [ webservice/3540734280 ] path: /emby/kodi/tvshows/148175/153742/file.strm?KodiId=765&Name=Die+Leute+von+der+Shiloh+Ranch+-+S05E06.avi&Id=153742 params: {'KodiId': '765', 'Name': 'Die Leute von der Shiloh Ranch - S05E06.avi', 'Id': '153742'}
Link to comment
Share on other sites

flatline69

 

Ah yes I see what you mean. That I cannot fix. Do try to repair your library to rule out some weird Kodi interference with the first resume dialog or something. What is your default play action again?

2019-02-23 07:04:53.855 T:3268268912 WARNING: <[ webservice/3434667584/0 ]
2019-02-23 07:04:57.153 T:3268268912 WARNING: [ webservice/3643990304 ] path: /emby/kodi/movies/49549/file.strm?KodiId=5&Name=13+Assassins+%282010%29.mkv&Id=49549 params: {'KodiId': '5', 'Name': '13 Assassins (2010).mkv', 'Id': '49549'}

Weird because my CE tester has no such delays. For example

2019-02-20 22:56:13.144 T:3354391408 WARNING: <[ webservice/3412848768/0 ]
2019-02-20 22:56:13.166 T:3354391408 WARNING: [ webservice/3540734280 ] path: /emby/kodi/tvshows/148175/153742/file.strm?KodiId=765&Name=Die+Leute+von+der+Shiloh+Ranch+-+S05E06.avi&Id=153742 params: {'KodiId': '765', 'Name': 'Die Leute von der Shiloh Ranch - S05E06.avi', 'Id': '153742'}

 

"The 6th Day" is my go-to test video. Last log I tested a few random titles, such as the one the above sample. Some formats do take longer to start playback than others, so I concede that in my testing. I hope I understood the question when you asked 'default play action'.

 

Do you happen to know what kind of box the other tester is using? Mine's a AMLogic S905D -- if the tester is using a S912 (for example) it'd be faster h/w than mine is whereas my S905D is faster than my other S905 boxes.

  • Like 1
Link to comment
Share on other sites

Angelblue05

"The 6th Day" is my go-to test video. Last log I tested a few random titles, such as the one the above sample. Some formats do take longer to start playback than others, so I concede that in my testing. I hope I understood the question when you asked 'default play action'.

 

Do you happen to know what kind of box the other tester is using? Mine's a AMLogic S905D -- if the tester is using a S912 (for example) it'd be faster h/w than mine is whereas my S905D is faster than my other S905 boxes.

What I showed you happens before the emby-loading video is returned to Kodi. This has nothing to do with the video itself, just somewhere Kodi has that delay between the HEAD request and the GET request. Could be just a slower device. But let's revisit once repair is completed.

 

No I do not know his device, I will find out next time.

 

The default action, like play or resume or show information or choose. In the Kodi settings > media settings.

 

EDIT: Maybe add a third option, ie: Emby-Loading, Blank or a static image w/loading on it?

EDIT: A static image may be more suitable to low-powered devices; betting if I tossed Kodi on my laptop it wouldn't seem like a delay at all but entirely different beast. Although it's "unsupported"; my Android TV boxes have CE written directly to the internal flash (vs external USB/SDCARD as per recommendation) which is fast enough (for DB transactions, loading images, etc) but not the fastest and probably contributes to the delay perception. Images load faster than videos off the medium in this use-case. Just a rambling train of thought with my morning coffee while I wait for the repair to finish.

How would that work exactly? So let's say, you start playback, Kodi calls the add-on, the add-on returns the image. Won't Kodi skip to the next video?

 

Right now, Kodi calls the add-on, we return emby-loading which is paused. Meanwhile, the actual playlist is being setup. Once it is, it plays it. The pause is important since it allows us to create the actual playlist and add it for playback.

Edited by Angelblue05
Link to comment
Share on other sites

flatline69

What I showed you happens before the emby-loading video is returned to Kodi. This has nothing to do with the video itself, just somewhere Kodi has that delay between the HEAD request and the GET request. Could be just a slower device. But let's revisit once repair is completed.

 

No I do not know his device, I will find out next time.

 

The default action, like play or resume or show information or choose. In the Kodi settings > media settings.

 

How would that work exactly? So let's say, you start playback, Kodi calls the add-on, the add-on returns the image. Won't Kodi skip to the next video?

 

Right now, Kodi calls the add-on, we return emby-loading which is paused. Meanwhile, the actual playlist is being setup. Once it is, it plays it. The pause is important since it allows us to create the actual playlist and add it for playback.

 

Default play action: Play

 

Library is repaired, resume still does the same thing; two prompts. First is proper resume timestamp, second is -1 day, 23:59:59 and then skip ahead (now) to 2 titles from selected.

 

As for the machinations of how to make it work, I dunno, I'm a back-seat developer-wannabe. I leave that to smarter folks like you :) and from the sounds of it, not feasible to do in this context (static image.)

 

Attaching log, you'll see the repair happening so scroll down a bit to see the test after the repair.

01_KODI.zip

  • Like 1
Link to comment
Share on other sites

Angelblue05

Restart Kodi, I see the playback stop happening again. Let me know if that skip ahead still happens after you restart?

 

Strange the repair didn't work. That's what others who had that issue said worked.

 

For now, just go ahead and change the default play action to resume to get rid of that double prompt.

Edited by Angelblue05
Link to comment
Share on other sites

flatline69

OK will do. Just a quick update - out of curiosity, I tried the context menu "Play" and "Play from here" -- the first gave a resume prompt and returned to movie hub. Second gave resume prompt and picked up from where it left off.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...