svtplay-dl
svtplay-dl copied to clipboard
spaam
Problem downloading Disneydags from SVT Play
svtplay-dl versions:
3.1-5-gcb3612b
Operating system and Python version:
Raspbian GNU/Linux 10 (buster) Python 3.7.3
What is the issue:
Problems downloading "Disneydags" from SVT Play. Video is OK, but audio is truncated. Only a few minutes of sound at the beginning are downloaded. Subtitles are not downloaded. "WARNING: Can't download subtitle file". svtplay-dl -S --verbose https://www.svtplay.se/video/30315858/disneydags/disneydags-sasong-1-avsnitt-1
@andersm1019 seems to be a publishing issue to me. DASH isn't available at all and the soundtracks spits out various error-code such as miss-matching sample rate etc... I have tried to fetch a variety of the soundtracks and they have all given different error codes.
Some of them gives me 3sec another one gives me 3minutes, some won't even start and try and download.
I would suggest contacting SVT so that they can troubleshoot this :)
All confirmed on my end, still works in streaming the episode, no loss of sound then ... oh well. :-D
Could this be a deliberate attempt to throw downloaders off-track, possibly because of some Disney requirements? "Doctor McStuffins", which was published today, and is also from Disney, has the same odd behavior. https://www.svtplay.se/doktor-mcstuffins
Could this be a deliberate attempt to throw downloaders off-track, possibly because of some Disney requirements? "Doctor McStuffins", which was published today, and is also from Disney, has the same odd behavior. https://www.svtplay.se/doktor-mcstuffins
This also lacks DASH, which will lead to playback issues for users and SVT have to strive for compatibility.
looking at the web browser. its using the different HLS than the script chooses 🤔
As you said before ... "Interesting ..." Another somewhat interesting observation is that youtube-dl fails in downloading this, in exactly the same way, sounds stops for that download as well, at the same time stamp ... Usually, if one fails the other works, or different behaviour somewhere, but not so this time.
/Dennis
I noticed a similar error some time ago, see closed issue #1307 A couple of days later there was no error anymore, download was successful with full sound, and I closed the issue assuming that it was caused by a temporary error by SVT.
they are using fragmented mp4 (fmp4) i hls. i guess something is wrong somewhere when the script download the files.
pretty weird. using other hls playlists , it always stop at that 3min 28s . even with ffmpeg
I observed something. I made a copy of the two .ts files before they were automatically merged and it seems the audio.ts file does have the correct audio all the way. However the video ts file contains truncated audio (it gets cut off around 3 minutes 28s in), which I guess is what the resulting .mp4 ends up using.
interesting observation. 🤔 if that is the case, with some ffmpeg arguments should be possible to fix it
So a workaround right now would be to temporarily rename the ffmpeg-binary (since it seems like there is no option to make svtplay-dl skip the merge (or remux)) then run the command so that it keeps the .ts-files.
Then figure out what ffmpeg-command is needed merge the files correctly. @spaam: Any idea of what arguments could help?
i guess map would be a thing to fix it to tell ffmpeg which audio and video track to use for the end file.
like something ffmpeg -i video.ts -i audio.ts -map 0:1 -map 1:1 -c copy -bsf:a aac_adtstoasc output.mp4 if the first track in video.ts is the video and the first track in audio.ts is the audio. if the tracks is different , just run ffmpeg -i file.ts to see which one is correct :)
So a workaround right now would be to temporarily rename the ffmpeg-binary (since it seems like there is no option to make svtplay-dl skip the merge (or remux)) then run the command so that it keeps the .ts-files.
Then figure out what ffmpeg-command is needed merge the files correctly. @spaam: Any idea of what arguments could help?
Sorry but i do not think this is a solution
You will get:
Invalid data found when processing input
So a workaround right now would be to temporarily rename the ffmpeg-binary (since it seems like there is no option to make svtplay-dl skip the merge (or remux)) then run the command so that it keeps the .ts-files. Then figure out what ffmpeg-command is needed merge the files correctly. @spaam: Any idea of what arguments could help?
Sorry but i do not think this is a solution You will get:
Invalid data found when processing input
MKVToolNix will happily mux the video and audio into an MKV-container. Once you've done that, you can use ffmpeg to remux it into an MP4-container if that's what you prefer.
Also, I've made some instructions for how to manually download the subtitles for now: https://www.dubbningshemsidan.se/forum/index.php?topic=3212.750
So a workaround right now would be to temporarily rename the ffmpeg-binary (since it seems like there is no option to make svtplay-dl skip the merge (or remux)) then run the command so that it keeps the .ts-files. Then figure out what ffmpeg-command is needed merge the files correctly. @spaam: Any idea of what arguments could help?
Sorry but i do not think this is a solution You will get:
Invalid data found when processing inputMKVToolNix will happily mux the video and audio into an MKV-container. Once you've done that, you can use ffmpeg to remux it into an MP4-container if that's what you prefer.
Also, I've made some instructions for how to manually download the subtitles for now: https://www.dubbningshemsidan.se/forum/index.php?topic=3212.750
Yes, but the audio tracks are still malformed....Which might be the reason why DASH-streams isn't available.
For what it's worth; The issue is at hand with the movie "Valyrie"/"Valkyria" when you choose to retrieve a version with 2-channel sound. If you instead choose to get a version "h264-51" the sound is complete and correct. I know it's not so much of a help with the items in this thread since these do not have the 5.1 option, sorry.
🤔 this is so weird. when i use ffmpeg to download its the same issue. when i use vlc it works.
Well, we can complain all we want that there's something wrong with SVT's streams. Still, it seems that there are no problems playing these programs in web browsers or apps, and that's really all that SVT can be expected to support. The errors may very well be intentional to discourage downloading attempts. Remember, this is Disney, and they may have their own agenda.
Since the first episode of Disneydags is about to be taken down by SVT, it was critical to find a workaround. I can live with that, but it would of course be more convenient if svtplay-dl could download the episodes without any special tricks.
As for the subtitles, there IS a problem that SVT has confirmed, but they have yet to fix it.
Well, we can complain all we want that there's something wrong with SVT's streams. Still, it seems that there are no problems playing these programs in web browsers or apps, and that's really all that SVT can be expected to support. The errors may very well be intentional to discourage downloading attempts. Remember, this is Disney, and they may have their own agenda.
Since the first episode of Disneydags is about to be taken down by SVT, it was critical to find a workaround. I can live with that, but it would of course be more convenient if svtplay-dl could download the episodes without any special tricks.
As for the subtitles, there IS a problem that SVT has confirmed, but they have yet to fix it.
The thing is that they don't play fine, on all devices,systems or browsers. Since there are no DASH-streams available.
I have been in contact with SVT thru email about the lack of DASH streams and they have acknowledged the issue but they are unable of providing. a timeline of when it will be fixed.
also as I have pointed out before there are issues with the audio tracks which ffmpeg correctly raises and therefor fails. This is a consistent issue that is repeated with all episodes. So there might and probably is an issue with SVT's new compressions model that they use for animated content.
The thing is that they don't play fine, on all devices,systems or browsers. Since there are no DASH-streams available.
I believe you. Which devices, systems and browsers have problems?
I have successfully played the Disneydags and the Doc McStuffins shows in several browsers like Firefox, Chrome and Edge, and in the apps on iPhone, iPad and Apple TV. Also, using the unofficial SVT Play add-on for Kodi on Raspberry Pi.
Everything works fine, except the subtitles, which only seem to work at random.
I have been in contact with SVT thru email about the lack of DASH streams and they have acknowledged the issue but they are unable of providing. a timeline of when it will be fixed.
Thank you! I too would contact SVT if I could find a system where the shows can't be played. I've been in contact with them regarding the subtitle issue. They have even claimed that problem to be solved, but then realized that it wasn't the case.
also as I have pointed out before there are issues with the audio tracks which ffmpeg correctly raises and therefor fails. This is a consistent issue that is repeated with all episodes. So there might and probably is an issue with SVT's new compressions model that they use for animated content.
Are there other animated shows that are affected in the same way? I thought it was only the two Disney shows because of special requirements by Disney to protect their content.
The thing is that they don't play fine, on all devices,systems or browsers. Since there are no DASH-streams available.
I believe you. Which devices, systems and browsers have problems?
The browsers I have had playback issues with are Android on various devices both thru their own app and thru i.e Chrome.
I have also had issues with playback thru Safari.
The issue is not only that DASH is non-existing, not all HLS-manifest doesn't seem to work properly either as spaam also has pointed out earlier. One manifest is for example loaded but then re-directed to another that works. On some episodes I think there are examples also where only one or two HLS-manifests actually returns working streams.
Have also noticed that these videos are more geo-striated and they have block VPN IP:s, which they don't do on other content.
I have successfully played the Disneydags and the Doc McStuffins shows in several browsers like Firefox, Chrome and Edge, and in the apps on iPhone, iPad and Apple TV. Also, using the unofficial SVT Play add-on for Kodi on Raspberry Pi.
Everything works fine, except the subtitles, which only seem to work at random.
I have been in contact with SVT thru email about the lack of DASH streams and they have acknowledged the issue but they are unable of providing. a timeline of when it will be fixed.
Thank you! I too would contact SVT if I could find a system where the shows can't be played. I've been in contact with them regarding the subtitle issue. They have even claimed that problem to be solved, but then realized that it wasn't the case.
The latest message I received they stated that they don't have any prognosis of when it will be solved but they mentioned that this is because the problem is substantial.
also as I have pointed out before there are issues with the audio tracks which ffmpeg correctly raises and therefor fails. This is a consistent issue that is repeated with all episodes. So there might and probably is an issue with SVT's new compressions model that they use for animated content.
Are there other animated shows that are affected in the same way? I thought it was only the two Disney shows because of special requirements by Disney to protect their content.
I don't really rip that much animated content in general so can't answer that but I would be surprised if this is the only content that is affected by it.
SVT has started using a new compression model for animated content (heavier) (Link - Source of statement (can also be observed in their manifests in comparison with "Normal Content").
Sure they use some basic encryption for it but not DRM. I mean they have apply the same encryption to their live streams of channels before and other content too, that part is nothing new really I would say.
I have the same issue with the feature film"Birdman" that was released at SVTplay today. Only HLS is available and sound cuts off after approx 3min 26sec.
This afternoon the sound is suddenly ok with "Birdman". One thing that's changed is that SVT suddenly made 5.1-sound an available option and selecting that provided me with full-length sound.
The issue of truncated audio seems to be spreading.
I found that it's at hand with most (all?) items under the link https://www.svtplay.se/faret-shaun At testing I'm using svtplay-dl v4.0. With this I'm using python 3.8.10, MS Windows 8.1, and ffmpeg 4.4.
If I try a "quality" different from the default highest one, I do at many times end up with an .mp4-file of diminished size (1 kB), i.e. with no playable content.
🤔 what quality and what video? i dont want to try to find what video when its 10+ videos with 10+ different quality options for each video.
Fair enough.
I get the symptoms using svtplay-dl with one switch only; the switch "--subtitle" to attempt to retrieve subtitles Some example links where audio is cut off: https://www.svtplay.se/video/9783602/faret-shaun/faret-shaun-sasong-5-avsnitt-16 https://www.svtplay.se/video/9862155/faret-shaun/faret-shaun-sasong-5-avsnitt-18 https://www.svtplay.se/video/29172470/faret-shaun/faret-shaun-sasong-6-far-a-gas https://www.svtplay.se/video/9888258/faret-shaun/faret-shaun-sasong-5-avsnitt-19 https://www.svtplay.se/video/9809841/faret-shaun/faret-shaun-sasong-5-avsnitt-17 https://www.svtplay.se/video/9942403/faret-shaun/faret-shaun-sasong-5-avsnitt-20
Additional info: Neither of the above is retrieved with subtitles However, with the two example links below (using the same setting with svtplay-dl) I succeeded to get full audio: https://www.svtplay.se/video/29155250/faret-shaun/faret-shaun-sasong-6-frakt-forhinder https://www.svtplay.se/video/29139718/faret-shaun/faret-shaun-sasong-6-lada-uthyres and, I also got subtitles with these two.
this is so random. i dont know wtf is wrong. when i use ffmpeg to download it , it works. but it would be nice to know why it works in ffmpeg. it would also be nice to know how to detect this thing. i dont wanna make this script as a frontend to ffmpeg more than it is know.