thats weird, I have audio and it works fine on android. I wonder if I need to transcode the mp3 to like 128-bit circa 1999 formats to make every player happy…
what sort of parallel universe are we in where groove music player is fine but vlc doesnt work… thats… odd.
I am noticing on CastBox on Android the stalling after 10 minutes or so is still a thing. I listen to other podcasts like Brian Lundukes and they play all the way through fine so I don’t think its the App.
It shows as buffering forever with no end. Tried multiple recent news eps now and all the same.
which episode? last weeks?
Most recent one (In terms of release) I’ve tried is March 5th 2019: You can tell by the way I use my walk…
Apologies Wendell. Error on my part. Think I got confused cause the App autodownloads the most recent episodes.
March 5th is fine. Listened to that one on the way in this morning for a good 60 minutes.
The most recent one that has issues for me seems to be Feb 26th.
@wendell I think I have discovered the issue.
I tried playing this audio file from the podcast feed:
It sounded corrupted. I used the trusty file command to see if it could tell us more about why it isn’t playing properly in VLC or iTunes.
$ file /Users/yeahboi/Downloads/vG9tEtGv3Ss.mp3 /Users/andrewhyatt/Downloads/vG9tEtGv3Ss.mp3: WebM
It is because it is in fact in WebM format, not MP3 at all. Changing the extension to .webm made it play in VLC.
TL;DR: While the extension is mp3, the file format is actually WebM.
@wendell it looks like the script to update the podcast feed was run again this weekend. Unfortunately, they are still WebM instead of MP3. Please look into this. If you post the scripts you’re using I could debug them to fix this. Let me know if we can do anything to help! The podcast feed is essential for me listening to podcasts on my phone and I miss out on Level1News a lot because I only have time to listen to podcasts when I’m on the go and not at my computer. Thanks for looking into this.
It’s literally just youtube-dl --audio-format mp3 at this point? The version of youtube-dl was updated to latest a bit ago.
--no-call-home -v --print-traffic --no-cache-dir --user-agent "<$USE-YOUR-OWN>" -f m4a -- 8AndP3g_8ns
in case this is somehow useful, -f m4a grabs best quality mp4. never had the issue of webm inside an mp4 before that sounds like a bug, or that the
-o output thing is appending
.mp4 to a non mp4 file because if the output module is writing .mp4 as a string rather than the native file extension…
I could make changes to it on github if you wanted to put it up…
I don’t want to waste people’s time, but I’m happy to improve the script if I can.
Looking at the file…
The image below shows Opus audio in a matroska webm file, with file extension .mp3
so this was an amazing troubleshoot. The problem ended up being the database character set needed to be utf8mb4
Why? Because some of the titles have emojii.
…but why would that break the conversion process?
Yes, yes. I know. This troubleshoot was amaaaaazing. There is a fallback code path that queues up the conversion in case the cron job runs a foul of its memory limits or time conversion limits (some loooong episodes of the news). Once you hit a landmine episode here the rest of the queue processes here.
When that conversion runs, youtube-dl does work fine, there was some problem accessing ffmpeg, so it just silently doesn’t convert to mp3. (But it does sometimes when this conversion runs as the web server user. As long as it fits within memory and time bounds.)
So I’m fixing the character set which. Which will take some hours to run. Will need to re-run some conversions after that. Maybe fixed later today.
Edit: Ooops. Well that fixed some stuff but broke some other stuff. Soon ™
bwahahaha, so, turns out.
–audio-format mp3 works GREAT…
UNLESS (dramatic music plays) you use -o to specify the output.
MOST OF THE TIME it will tell you ‘hey, you can’t have the output file be the same because I’ve got to get the webm then I convert it to mp3’ BUT if you specify the filename as mp3, it seems to fail silently.
But you don’t end up with an mp3.
No idea when this stopped working. I suspect a debian maintainer fixed this… then… stopped fixing it. Some time ago. Or, possibly, something changed in the past and no one noticed.
So you MUST use the output template.
The actual sequence is youtube-dl (gets a web m) then youtube-dl goes back and converts that webm to an mp3. then trashes the webm (unless you specify -k). Unless you just name the -o file mp3, which was happening in our fall-through case, which meant that nope, no actual conversion takes place.
Man. Computers are hard
youtube-dl --no-call-home -v --print-traffic --user-agent “Firefox/1.0” --extract-audio --audio-format mp3 -o “/tmp/r4Pehb7_8dkB.%(ext)s” https://www.youtube.com/watch?v=r4Pehb7_8Dk
that %(ext)s was the other half of the magic here. Talk about a misfeature!
Dude, thank you so much. You guys make three mornings a week better. Having this on a podcast is so much more convenient than using NewPipe to manually download the audio. (I also love that you read out the titles and source audibly, makes it easier to follow when listening).