Closed pnperehod closed 10 months ago
All live streams play only sound - no video
All work fine for me
It seems that add-on considers every stream as audio only
It seems that add-on considers every stream as audio only
It obviously does not do that. If that is happening on your system then you need to provide a debug log showing the problem.
Hi,
i got the same problem. Without MPEG-DASH i had live Videos without picture and just audio. I switched to Inputstream Adaptive and most of the videos work, but still a lot (this can be live videos and non-live videos) fail like that:
I just clicked once on opening that video, but it loops until even Kodi crashes.
Best regards and thanks for any hint.
That is not a debug log. It is not even a complete log. Can't tell what platform you are using, what version of InputStream.Adaptive you are using, or what it is doing.
Without MPEG-DASH i had live Videos without picture and just audio.
That is extremely unusual because it means that Kodi is failing to play a HLS TS live stream using FFmpeg, which is functionality that hasn't changed in Kodi, this plugin or Youtube, for years.
I just clicked once on opening that video, but it loops until even Kodi crashes.
The plugin won't repeatedly try to run itself to open a video, like what is shown in your log. Something else is creating that continuous loop, and that is what eventually causes your crash.
but still a lot (this can be live videos and non-live videos) fail like that
Live videos and VOD are handled very differently and I can't confirm any issue causing "a lot" of both types of video to fail.
Best regards and thanks for any hint.
Produce a debug log showing whatever problem you are having with live and non-live videos. For live videos you should use
Settings > MPEG-DASH > Use for live streams > Adaptive HLS
This is the debug log: https://pastebin.com/r3TzvDD7
The plugin won't repeatedly try to run itself to open a video, like what is shown in your log. Something else is creating that continuous loop, and that is what eventually causes your crash.
I see. Well i use "Cast Kodi" Firefox Plugin to queue the Video. I have to check if that is causing it, but i used it for years without anything like that. That all is happening since upgrading from Kodi from 19.4 to 20.2 and Debian bullseye to bookworm.
I do use Adaptive HLS for live streams.
Thanks a lot for your help!
Unfortunately I can't open the pastebin link. Can you check that is the correct link, or alternatively attach the log directly in a reply to this message in Github?
I see. Well i use "Cast Kodi" Firefox Plugin to queue the Video. I have to check if that is causing it, but i used it for years without anything like that. That all is happening since upgrading from Kodi from 19.4 to 20.2 and Debian bullseye to bookworm.
It is easier to figure things out if there is only one thing going wrong at a time. For the moment can you try playing without the that addon? There is an issue with the playback of the live stream itself, but can look at what may be causing the playback loop after the first issue is investigated.
I do use Adaptive HLS for live streams.
The log snippet indicates that there are no audio or video streams found in the HLS manifest being used to play the video. The manifest is created by Youtube and used without modification, so not sure why it would be failing like that.
Was that actually a live stream? It is no longer live, so just speculating, but perhaps the manifest was retrieved during a time when stream had already finished and was being converted to a VOD? Normally when a live stream finishes, the manifest is no longer provided and the Youtube plugin has to find the video and audio stream to play.
Do you still have the same problem if you play the video now?
Is this problem happening on other live and non-live videos? If so please provide a debug log.
The debug.log is attached, not sure why pastebin has removed it though...a bit strange.
Yes, the Video was a live and then got in the status "was streamed X minutes/hours ago" so i guess it "became" a normal video. I cant play it in both stati when using MPEG-DASH with Adaptive HLS for livestreams. When i uncheck the "Use MPEG-DASH" option, i can play it now. At least in the status when it is a normal video. However, i switched to using MPEG-DASH because when it is actually live, i only get audio. So to say, i only can play the video if a) its not live anymore and b) i am not using MPEG-DASH. When using MPEG-DASH it crashes Kodi if its live or not. When not using MPEG-DASH it only has audio when its live and plays normal when its not live anymore.
The debug.log only shows using MPEG-DASH with Adaptive HLS when the video was not live anymore. I'll try to make more debug.log's for situation when its live using MPEG-DASH/Adaptive HLS (Kodi Crash) or when its live and not using MPEG-DASH at all (only audio).
Thanks again for your great help. kodi_crashlog-20231203_224140.log
The debug.log only shows using MPEG-DASH with Adaptive HLS when the video was not live anymore.
That definitely helps. It shows the plugin is successfully creating a MPEG-DASH manifest and that it is being loaded, but is being loaded as a live HLS manifest, which then fails Suspect there must be a bug where the plugin still thinks the video is live even when it is creating a non- live manifest. Will look into it.
When using MPEG-DASH it crashes Kodi if its live or not.
This seems to be related to the multiple concurrent play requests. Does this also occur when not using Cast Kodi?
When not using MPEG-DASH it only has audio when its live and plays normal when its not live anymore.
As indicated previously, this is quite unusual and I can't replicate the problem myself. Would be interesting to see what the log shows is happening.
Thanks again for your great help.
All good, your input in describing the problem properly and providing logs are a great help.
When using MPEG-DASH it crashes Kodi if its live or not.
The attached debug.log shows what happens if the Video is started via OSD and not using Cast Kodi. It also crashes Kodi. So the debug.log is the same as before, just not using Cast Kodi to queue the video. kodi_crashlog-20231204_132200.log
(I see in line 1069: info
As indicated previously, this is quite unusual and I can't replicate the problem myself. Would be interesting to see what the log shows is happening.
This log contains: Video: Actually LIVE Method: No MPEG-DASH Result: Audio Only
This log contains: Video: Actually LIVE Method: MPEG-DASH/Adaptive HLS Result: Kodi Crash
Suspect there must be a bug where the plugin still thinks the video is live even when it is creating a non- live manifest. Will look into it.
(I see in line 1069: info : AddOnLog: inputstream.adaptive: Successfully parsed manifest file (Periods: 1, Streams in first period: 0, Type: live --- i guess that is what you mean, the video is not live anymore)
Yes - what is happening is that the metadata retrieved from when the video was live is being cached and still being re-used when the video is a normal on-demand video. This results in the plugin indicating to InputStream.Adaptive that the generated manifest is a different type to what it actually is.
I didn't notice because this bug has already been fixed in the test code I use, and also because I am using Kodi v21 and the associated compatible version of InputStream.Adaptive, where the manifest type no longer needs to be set, and is instead detected automatically.
So this particular issue will be fixed in the next release of the plugin and/or the next release of Kodi/InputStream.Adaptive
The attached debug.log shows what happens if the Video is started via OSD and not using Cast Kodi. It also crashes Kodi.
How exactly are you starting the video? It is still showing a new video starting almost immediately after the first video is requested, except this time it is a completely different video.
The end result is the same though, a busy dialog is being created for the second video, while the busy dialog is still open for the first video that failed, which causes Kodi to close itself on purpose.
Normally wouldn't see this problem because the first video should play normally, so the second video wouldn't be started so soon, but will need to see if the busy dialogs can be monitored, and closed before another is opened, rather than relying on the timing of the playback sequence.
This log contains: Video: Actually LIVE Method: No MPEG-DASH Result: Audio Only
This is interesting - it is showing that only audio streams are being found in the video info being supplied by Youtube. However the video info being supplied by Youtube is also indicating that the video is not a live video.
I think what is happening is that you are trying to watch a live stream that has recently finished and the normal VOD streams are not yet available.
A workaround for a similar issue has already been included in the test code, so I think this should be fixed in the next release. At the very least I can't replicate the same issue when using the test code, but it may need more testing to confirm it fixes this particular issue as well.
This log contains: Video: Actually LIVE Method: MPEG-DASH/Adaptive HLS Result: Kodi Crash
This is just a combination of all of the above - this is not actually a live video, however the cached data being used is signalling to InputStream.Adaptive that it is. While it is no longer live, the normal video streams also don't seem to be available yet.
As for the crash, it is the same cause - Kodi purposefully crashing due to concurrent busy dialogs. This time the same video is being requested to play over and over again. How did you start the video in this instance?
Yes - what is happening is that the metadata retrieved from when the video was live is being cached and still being re-used when the video is a normal on-demand video.
The strange thing about that is, that it happens when i play an complete "fresh" video that the YT Plugin "never has seen". As long as the YT Plugin doesnt cache/parse all my subscriptions in the background every X minutes, but tbh, that cant be the case. Often i click one minute after a Video goes live on play, the YT Plugin can't have "seen" this video anywhere. So i dont understand where the cached data comes from... On the other hand, would it help to delete this cache before trying to play it?
How exactly are you starting the video? It is still showing a new video starting almost immediately after the first video is requested, except this time it is a completely different video.
I did use my TV remote(CEC) to navigate Addons > Youtube > Liked Videos (liked the video to find it quickly in Kodi) > Press play in this list of liked Vidoes. So i guess Kodi somehow notices "I cant play liked Video #1, lets start playing liked Video #2" (while sill trying to play #1 though :P)
I think what is happening is that you are trying to watch a live stream that has recently finished and the normal VOD streams are not yet available.
When i did the debug.log the Video was actually LIVE. It went into "was streamed X minutes ago" state about 20 minutes after i did that log. And as soon as it is no more live, really one minute after, i can play it normally (what i did).
This is just a combination of all of the above
I know, just for the completeness ;) It is the same Video as that audio-only in the same state trying to get with Adaptive HLS.
The strange thing about that is, that it happens when i play an complete "fresh" video that the YT Plugin "never has seen". As long as the YT Plugin doesnt cache/parse all my subscriptions in the background every X minutes, but tbh, that cant be the case. Often i click one minute after a Video goes live on play, the YT Plugin can't have "seen" this video anywhere. So i dont understand where the cached data comes from... On the other hand, would it help to delete this cache before trying to play it?
If that is actually the case, then no it probably won't help. Won't hurt to try though, except use up a bit more quota.
However, the what the log shows is pretty clear. The data is cached as soon as a video shows up in a directory listing of any kind. The log shows that the video has cached data, which makes sense given that it is being loaded from your liked list, as you must have added it to that list from somewhere, at some previous time. The log also shows that the video is not actually a live video when you are playing it.
This doesn't mean that there is not something else going on - there are currently a few issues with correctly displaying the date/time of live or premiering videos correctly so you may not actually be opening a video just after it goes live, and it may also be possible that the API data is lagging behind the actual video metadata.
In any case this should be resolved in the next release.
I did use my TV remote(CEC) to navigate Addons > Youtube > Liked Videos (liked the video to find it quickly in Kodi) > Press play in this list of liked Vidoes. So i guess Kodi somehow notices "I cant play liked Video #1, lets start playing liked Video #2" (while sill trying to play #1 though :P)
You must have the Play next video automatically
setting in Kodi enabled. Will need to see what can be done about managing the dialogs to try and prevent the crash.
When i did the debug.log the Video was actually LIVE. It went into "was streamed X minutes ago" state about 20 minutes after i did that log. And as soon as it is no more live, really one minute after, i can play it normally (what i did).
Next time this happens can you confirm that it shows up as a live video on the Youtube website? If it is, you should see a red dot and the word "Live" next to the volume icon on the video OSD. Just to check as well, can you right click on the video and see what the "Live mode" is?
The reason I am asking you to check is because the video data that has been retrieved from Youtube is indicating that, when you played the video, it was not live. If that data is not correct then will need to try and see what can be done to workaround the discrepency, if it is not already fixed by the previously mentioned workaround.
I know, just for the completeness ;) It is the same Video as that audio-only in the same state trying to get with Adaptive HLS.
How was this video started? It is trying to play the same video repeatedly.
However, the what the log shows is pretty clear. The data is cached as soon as a video shows up in a directory listing of any kind. The log shows that the video has cached data, which makes sense given that it is being loaded from your liked list, as you must have added it to that list from somewhere, at some previous time. The log also shows that the video is not actually a live video when you are playing it.
That this video has cached data is no wonder. Yes, before actually doing the debug.log i tried to play it to see if it really crashes Kodi, then did the debug.log. But tbh, the YT Plugin must get that information on initial retrieval wrong. When i first played it, i used Cast Kodi from my PC, the YT Plugin never saw it anywhere before. I'll try to make a debug.log of such an case, when the YT Plugin has no cached data and has to dig the info. Is it safe to delete the sqlite files in "~/.kodi/userdata/addon_data/plugin.video.youtube/kodion/" and is that where the cached data lives?
You must have the Play next video automatically setting in Kodi enabled. Will need to see what can be done about managing the dialogs to try and prevent the crash.
Yes exactly, i do have this option turned on.
Next time this happens can you confirm that it shows up as a live video on the Youtube website? If it is, you should see a red dot and the word "Live" next to the volume icon on the video OSD. Just to check as well, can you right click on the video and see what the "Live mode" is?
I will do so and provide a screenshot with time and date.
How was this video started? It is trying to play the same video repeatedly.
It was started using Cast Kodi.
But tbh, the YT Plugin must get that information on initial retrieval wrong.
Yes, this may be what is happening, just not sure how/why. As I mentioned, maybe the API data that is being retrieved is not being updated in a timely manner, but none of your logs show you playing an actual live video.
I know that the date/time display may not be accurate currently, but that is a plugin issue. If the actual API data is not accurate then the plugin may need to ignore the API data, and evaluate live status based solely on the date/time.
Is it safe to delete the sqlite files in "~/.kodi/userdata/addon_data/plugin.video.youtube/kodion/" and is that where the cached data lives
Yes but you can also manage the data or delete the files through the plugin settings: Settings > Maintenance
. You may need to scroll down past the other settings sections to see this.
It was started using Cast Kodi.
Hmm, will need to check what it is doing when sending the plugin url to Kodi. Can prevent the crash, but if it continuously tries to play the same video upon failure to play, then Kodi will just get hang instead.
I am sorry that i have to tell you that i may have informed you wrong, at least not nuanced enough. Up to today, i never noticed using YoutTube that there are actually two types of "live" streams. The true live streams and "pseudo live" streams which are called "Premiere" (at least in german). These pseudo livestreams aren't actually live, they are recored before and just released at that time. While that release they act like "livestreams" saying you can't skip a part or the like. Of course i knew that they're not actually live, but i never noticed that there is a technically difference between them and true live streams.
So everything is this thread is still valid, except that it does not apply to true livestreams, instead it does apply to those "Premiere" pseudo livestreams. As long as they are casted (you can't skip time, they are "pseudo live") the YT Plugin does not play them here at all. When the cast ends (i guess they become normal VODs then) you can play them if you delete the cache. So the hint why they are not playable when they are "pseudo live" might be found in that cached data. Of course you just have to delete the cache if you tried to play them while they where "pseudo live" and the YTPlugin cached something that makes the video unpalyable.
Actual, true livestreams are playing fine and without problems here with Adaptive HLS (as you assumed all over the thread :P). Again sorry, i didn't see the difference between livestreams and Premiere videos.
Attached a picture of those Premiere vidoes that don't work as long as they are "psuedo live" with "stats for nerds" from Youtube, i hope it helps:
Strange, but add-on plays live streams again without me changing any settings at all. Seems something is changing on youtube side. Funny, but now live streams play at 1080p, but all not live videos play no more than 720p. https://pastebin.com/FKvghFPw
@niceman20k - Yep thats what I suspected was happening. Anyway there are already fixes in place for the plugin to properly detect the differences between (upcoming) premieres and (upcoming) live videos in the next release, before and after they actually premiere/go live. Will be available in the next release.
@pnperehod - Based on the information provided by niceman20k, you are probably effected by the same issue with playing a premier and/or live video after it started/finished, when there was already cached data for that video from before it started. It may or may not work properly depending on the status of the cached data, but will be fixed in the next release.
The issue with completed live videos playing at max 720p was identified in #530 and there is a fix in place for that as well. Will also be available in the next release.
Yep thats what I suspected was happening. Anyway there are already fixes in place for the plugin to properly detect the differences between (upcoming) premieres and (upcoming) live videos in the next release, before and after they actually premiere/go live. Will be available in the next release.
Great, glad to hear that, i am looking forward to it. Thanks again for your great work and support!
Context
Please provide any relevant information about your setup
Expected Behavior
Add-on plays live streams normally
Current Behavior
All live streams play only sound - no video
Context
Please provide any relevant information about your setup
Steps to Reproduce