There are many reasons, unrelated to artist reimbursement, why Spotify is the dirt worst of the streaming platforms. I trust by now you are aware of these.

I want to make it very clear that I am not criticising anyone for using streaming platforms. Everyone streams, living is hell and we all love music. [...]

As you can see, the vast majority of people who streamed All Hell did so using Spotify. Unfortunately, of the major streaming platforms, Spotify pays significantly less per stream than anywhere else.

If everyone who streamed All Hell on Spotify had done so using Tidal instead, we would have received an extra £31,847.38, which would double the amount we made from streaming of the album in this time period. Or if everyone used Apple Music it would have been £12,331 more.

Relatedly, today is Bandcamp Friday when 100% of your money goes to the artists.

"But what do you use, jwz?" none of you are asking. I'm glad you asked! I do not use any streaming platforms. I purchase music as files that then live on my computers and computer-like devices that are backed up on hard drives that I own. I listen to them with headphones that have analog cables.

When at all possible, I purchase music from Bandcamp, because of all the options available, that is the one where the artists make the most money.

When an album is not available on Bandcamp (as often happens with bands signed to major labels who contractually prohibit the bands from making their music available on Bandcamp) I have been using Qobuz, which seems to be the least-bad second option at this time. The files are high quality and DRM-free.

Previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2025/12/los-campesinos-on-streaming/feed/ 45 https://www.jwz.org/blog/2025/11/the-algorithm-failed-music/ https://www.jwz.org/blog/2025/11/the-algorithm-failed-music/#comments Tue, 11 Nov 2025 21:35:56 +0000 https://jwz.org/b/ykxT Music recommendation algorithms were supposed to help us cut through the noise, but they just served us up slop.

Spotify leadership didn't see themselves as a music company, but as a time filler. The employee explained that, "the vast majority of music listeners, they're not really interested in listening to music per se. They just need a soundtrack to a moment in their day."

Simply providing a soundtrack to your day might seem innocent enough, but it informs how Spotify's algorithm works. Its goal isn't to help you discover new music, its goal is simply to keep you listening for as long as possible. It serves up the safest songs possible to keep you from pressing stop. [...]

Artists, especially new ones trying to break through, actually started changing how they composed to play better in the algorithmically driven streaming era. Songs got shorter, albums got longer, and intros went away. The hook got pushed to the front of the song to try to grab listeners' attention immediately, and things like guitar solos all but disappeared from pop music. The palette of sounds artists pulled from got smaller, arrangements became more simplified, pop music flattened. [...]

It found that while new music discovery is traditionally associated with youth, "16-24-year-olds are less likely than 25-34-year-olds to have discovered an artist they love in the last year." Gen Z might hear a song they like on TikTok, but they rarely investigate beyond that to listen to more music from the artist.

Previously, previously, previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2025/11/the-algorithm-failed-music/feed/ 50 https://www.jwz.org/blog/2025/06/further-hls-antics/ https://www.jwz.org/blog/2025/06/further-hls-antics/#comments Fri, 13 Jun 2025 21:27:27 +0000 https://jwz.org/b/ykpW I think maybe I have gotten the DNA Lounge webcast behaving better, but not entirely, and I could use some help understanding what's going wrong.

I think one of the things that did help was increasing the segment size from 2s to 6s, which flies in the face of 100% of the advice online.

I have also gotten my hls-continuity thing working again, which is the HLS proxy that I wrote with the intent that the stream should never stop sending video even when the source disconnects. I had to basically rewrite it to work with mediamtx instead of nginx, and I don't really understand what about it meant that it had been working fine with nginx, but was working decidedly not-fine with mediamtx. But it seems to mostly be working now?

A few things about it are a little wonky, and if someone who understands this crap could help me diagnose this, that would be greatly appreciated:

1. When it goes into colorbars mode, the player often does a little "loading" animation for a few seconds before showing the first colorbars segment. I absolutely do not understand why this is, because the m3u8 file already has the proper duration and number of segments. I believe all segments start with a keyframe.

2. When coming out of colorbars mode and going back to real video, sometimes the video frame is frozen. Audio continue playing. Video comes back "after a while" or if you bonk the play-head slider.

3. When I was serving the raw, non-proxied stream from mediamtx, the player's play-head behaved as I expected: always pegged to the right side, with the "live" light lit up. But with my proxy in place, very often the play-head will end up lagging behind. Even when colorbars are not involved. Dragging it to the right or bonking the "live" button brings it back, but shortly it happens again.

   As the proxy does not transcode video -- it uses exactly the same TS files, just with a regenerated m3u8 file with different sequence numbers -- I do not understand how this is possible or what is different.

4. Sometimes I'll go a whole day without it going into colorbars mode. Sometimes, like right now for instance, it happens a lot, and usually for short durations, like 12 seconds / 2 segments. It seems that mediamtx is behaving as if the source had disconnected and then immediately reconnected. I don't know whether to blame OBS, mediamtx, Monkeybrains, or all three.

   OBS consistently says 0 dropped frames, 4% CPU.

   Sometimes I see this: the internal mediamtx will say:

   2025/06/13 14:06:14 WAR [RTMP] [conn [::1]:52386] connection is too slow, discarding 2 frames 2025/06/13 14:06:15 WAR [RTMP] [conn [::1]:52386] connection is too slow, discarding 26 frames 2025/06/13 14:06:18 WAR [RTMP] [conn [::1]:52386] connection is too slow, discarding 10 frames 2025/06/13 14:06:19 WAR [RTMP] [conn [::1]:52386] connection is too slow, discarding 37 frames 2025/06/13 14:06:20 WAR [RTMP] [conn [::1]:52386] connection is too slow, discarding 35 frames 2025/06/13 14:06:21 WAR [RTMP] [conn [::1]:52386] connection is too slow, discarding 2 frames 2025/06/13 14:06:25 INF [RTMP] [conn [::1]:52386] closed: too many reordered frames (27) 2025/06/13 14:06:30 INF [RTMP] [conn [::1]:52427] opened

   and the external one will say:

   2025/06/13 14:06:25 INF [RTMP] [conn 52.119.114.44:52388] closed: EOF 2025/06/13 14:06:25 INF [HLS] [muxer live] destroyed: terminated 2025/06/13 14:06:33 INF [RTMP] [conn 52.119.114.44:52429] opened

   This sounds like the server is hanging up on OBS and it is reconnecting, but OBS doesn't give me any indication of that.

   It says a connection is too slow, but how could the connection between localhost OBS and localhost mediamtx be too slow, with 4% OBS load, load average 1.7, on a Mac mini M1? OBS is using Apple hardware MPEG encoding. (Or when it says "too slow" is it referring to the outgoing uplink connection? How would it even know?)

5. Also sometimes the external server says this, which, WTAF, how is this even possible? Sometimes that number just keeps going up:

   2025/06/13 14:13:08 WAR [HLS] [muxer live] segment duration changed from 6s to 8s - this will cause an error in iOS clients

Ways in which you could help me out with this:

1. Examine the DNA Lounge video stream as-is, and tell me what seems to be wrong with it; or

2. Run hls-continuity.pl on your own system, proxying your own OBS / mediamtx stream, and see if you can detect any problems with that when you toggle the source on and off.

The Bothans thank you in advance.

Previously, previously, previously.]]> https://cdn.jwz.org/blog/2025/06/further-hls-antics/feed/ 32 https://www.jwz.org/blog/2025/06/welp-mediamtx-glitches-out-too/ https://www.jwz.org/blog/2025/06/welp-mediamtx-glitches-out-too/#comments Wed, 04 Jun 2025 17:54:20 +0000 https://jwz.org/b/ykor

1. After the mediamtx stream was up for ~16 hours, OBS started doing the thing on the right. Disconnecting and reconnecting fixed it, but my check-volume.pl script did not detect it and so could not auto-reset it. Any ideas on either how to make it never do this, or how to detect it?

2. What does this mean and how do I make it go away? "WAR [HLS] [muxer live/live] segment duration changed from 1s to 2s - this will cause an error in iOS clients".

3. Is there any reason to try to get hlsVariant "lowLatency" working instead of "mpegts"? What are the downsides? (Besides that check-volume.pl doesn't understand that format.)

4. Other annoyances.

Previously.]]> https://cdn.jwz.org/blog/2025/06/welp-mediamtx-glitches-out-too/feed/ 8 https://www.jwz.org/blog/2025/05/rtmp-hls-segment-corruption/ https://www.jwz.org/blog/2025/05/rtmp-hls-segment-corruption/#comments Wed, 28 May 2025 03:37:09 +0000 https://jwz.org/b/ykoc Dear Lazyweb,

When my internal video encoder machine relays its RTMP stream to the external public server, MPEG glitches get introduced, and I would like to know how to fix that.

I am hoping for answers from someone who actually understands how RTMP transports and reconstitutes MPEG frames, or who knows how to take these TS files apart and identify why they are glitching.

(I shouldn't have to say this but I do: If your suggestions are more along the lines of, "Have you tried changing this magic number in the config file?" without a coherent theory of why, then your suggestions are almost certainly unhelpful. Likewise, "Why don't you just..." ← not the question I asked.)

Details:

• Both machines are running nginx-1.17.10 and nginx-rtmp-module Feb 2022.

• Internal machine runs OBS 31.0.3 streaming to rtmp://localhost/live/

• Internal nginx rtmp is configured like so. Notably, hls_fragment 10s, hls_playlist_length 30s.

• External nginx rtmp is configured like so. Notably, hls_fragment 6s. Why are they different? I don't remember. At some point I thought that seemed to improve... something.

Here are some example TS files covering approximately the same time range from the internal and external streams. The the internal ones play fine; the external ones contain glitches.

The first handclap happens at around 6s in the internal stream, and 3s in the external, so if you plot the segments on a timeline, it looks like this. Asterisks indicate glitches. They don't correlate well to segment changes in either the internal or external streams.

 = 00 ext 1: 1748393053750.ts | 01 | 02 = | 03 int 1: 1748393056339.ts | | 04 | | 05 | = 06 ext 2: 1748393061627.ts (handclap) | | * 07 | | * 08 | | * 09 | | * 10 | | 11 | = 12 ext 3: 1748393066847.ts = | 13 int 2: 1748393066342.ts | | 14 | | 15 | | * 16 | | * 17 | = 18 ext 4: 1748393073414.ts | | 19 | | 20 | | 21 | | 22 = | 23 int 3: 1748393076343.ts | = 24 ext 5: 1748393079981.ts | | 25 | | 26 | | 27 | | * 28 | | * 29 | = 30 ext 6: 1748393086982.ts | | 31 | | 32 = | * 33 int 4: 1748393086341.ts | | * 34 | | * 35 | = * 36 ext end | 37 | 38 | 39 | 40 | 41 = 42 int end

Another thing that I don't understand, which is probably unrelated: when I pack these TS files into an MP4 with:

ffmpeg -f concat -i concat.txt -c copy out.mp4

the audio de-synchronizes by like half a second. Why?

Previously, previously, previously.]]> https://cdn.jwz.org/blog/2025/05/rtmp-hls-segment-corruption/feed/ 61 https://www.jwz.org/blog/2024/09/maybe-later-intensifies/ https://www.jwz.org/blog/2024/09/maybe-later-intensifies/#comments Tue, 17 Sep 2024 19:06:15 +0000 https://jwz.org/b/ykZU I can already see that I'm going to regret having upgraded one of my machines to macOS 15. Has anyone figured out how to make this dark-pattern patronizing bullshit permanently take "yes" for an answer?

Update: For the nag, possibly this works:

defaults write \ ~/Library/Group\ Containers/group.com.apple.replayd/ScreenCaptureApprovals.plist \ "/Applications/OBS.app/Contents/MacOS/OBS" \ -date "3024-09-21 12:40:36 +0000"

Update 2: As of macOS 15.1, it looks like the syntax of this plist has changed. Now it is:

defaults write \ ~/Library/Group\ Containers/group.com.apple.replayd/ScreenCaptureApprovals.plist \ com.obsproject.obs-studio \ -dict-add kScreenCaptureApprovalLastAlerted \ -date "3024-09-21 12:40:36 +0000"

For the premature locking, wiggle the mouse. Sigh.

Previously, previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2024/09/maybe-later-intensifies/feed/ 124 https://www.jwz.org/blog/2024/09/hls-sync/ https://www.jwz.org/blog/2024/09/hls-sync/#comments Sun, 01 Sep 2024 21:50:47 +0000 https://jwz.org/b/ykYt Dear Lazyweb, is there some way for JavaScript to know the timestamp of a VIDEO tag's currently-playing live HLS stream? Bu this I mean the wall clock at the time the video was encoded, not played. Think of this as a subtitle-sync problem.

Apple references something called "HLS Timed Metadata" which I gather is in-band ID3 frames within the MPEG stream, but the doc is an atrophied stub. On this demo page there is stuff visible in HTMLMediaElement.textTracks but I don't know how to make OBS and/or nginx-rtmp insert these sorts of ID3 tags, or whatever they are. (Remember, this is for a live stream, not a pre-recorded static file.)

The HLS RFC has a thing about EXT-X-SESSION-DATA but I have no idea what that's for or how it differs from just some random comment-line in the file; and it seems to only be for Master Playlists, not Media Playlists.

Things that don't work:

• HTMLMediaElement.currentTime -- this is the elapsed time since the user pressed play.

• Scanning the .m3u8 file from the SRC attribute directly -- there's no way to know which of those segments is currently playing, or where within that segment the play-head is.

Previously.]]> https://cdn.jwz.org/blog/2024/09/hls-sync/feed/ 12 https://www.jwz.org/blog/2024/08/just-play-the-damned-video-redux/ https://www.jwz.org/blog/2024/08/just-play-the-damned-video-redux/#comments Wed, 28 Aug 2024 19:01:33 +0000 https://jwz.org/b/ykYY I had an idea: what if I ingest the various HLS streams that nginx-rtmp spits out, and regenerate them with new segment sequence numbers, inserting colorbars segments when things fall behind? This should keep the output stream up even when the input stream drops out for a while, and will stop the client from having to reload.

This was a lot more work than it sounded like because the HLS / M38U format is a cargo-cult kit-bashed abomination that kind of "just happened".

In my opinion, this behavior should be built in to nginx-rtmp itself, but here we are.

Also I'm not entirely sure it's helping. If you're watching the webcast, let me know if it seems better or worse than it was yesterday.

Previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2024/08/just-play-the-damned-video-redux/feed/ 16 https://www.jwz.org/blog/2024/08/just-play-the-damned-video/ https://www.jwz.org/blog/2024/08/just-play-the-damned-video/#comments Sat, 24 Aug 2024 21:14:40 +0000 https://jwz.org/b/ykYE Dear Lazyweb, how do I just play the damned video?

If you watch the DNA Lounge video webcast for any length of time, it will eventually drop out. Sometimes it will start playing again automatically. Mostly not.

Problems causing this are manifold:

1. The uplink from DNA Lounge to AWS is via MonkeyBrains, and their legendary eight eights of uptime.

2. Downlink from AWS to my house is also MonkeyBrains.

3. I've got a big old pile of JavaScript on the player page that tries really hard to keep things playing via a deadman switch. But most of the time Safari says "nah".

Somehow YouTube manages to succeed in all of this. For a recent example, I left all four days of the DNC running in a browser window, 6 hours a day, and it didn't drop out once. The DNA webcast never lasts that long. This is interesting because it suggests that any MonkeyBrains antics in point #2 are not really the issue.

What am I doing wrong?

Obviously Google has a scale that is unachievable by mere mortals, but I'm also not serving that much video and not serving it to that many people, and I don't understand what differences in behavior between me and them are going on.

The internal machine's OBS streams RTMP to a localhost nginx (config) which uplinks to an AWS nginx (config) which then serves m3u8 segments to the outside world via CloudFront. It also downcodes to a lower resolution stream for client-side negotiation. Somehow this is all... insufficient.

Things that would be nice:

1. Make the internal stream stop failing to connect to the outside server. I assume this is unachievable because MonkeyBrains, but maybe that's not the problem and it's something else? Maybe my various magic numbers related to buffering and keyframes are wrong. I have no idea, it's all dark magic. "Just try some different values" is not a useful suggestion, because twiddling some knobs and then waiting a month to see if maybe things feel better maybe? is no way to debug things.

2. When the internal source stalls in feeding the external server, have that server keep serving blank or colorbars segments to the clients anyway, so that the outbound stream never actually disconnects from the viewer, but just awaits the return of the source. I tried that, it was a disaster.

3. Figure out how to get the video player client to actually keep re-trying when the video has stalled without requiring the user to click again. Maybe this is just impossible now? Maybe YouTube doesn't even do that, because somehow they have found a way to not need to, because their connection from the server to the client magically never drops out.

In summary, everything is terrible.

Previously, previously, previously.]]> https://cdn.jwz.org/blog/2024/08/just-play-the-damned-video/feed/ 28 https://www.jwz.org/blog/2024/06/the-ever-changing-rules-about-autoplay-2/ https://www.jwz.org/blog/2024/06/the-ever-changing-rules-about-autoplay-2/#comments Thu, 13 Jun 2024 19:16:48 +0000 https://jwz.org/b/ykVI

Safari:

Also Safari:

After clicking in the window (but not on the video), calling play() works again. For a while.

That setting is supposed to disable the restriction that code may only play a video if there is a user event in the invoking event chain. It doesn't.

There also seems to be another undocumented restriction that if a video was already playing and stops (e.g., due to a network error) your code can start it playing again... for a while. But some time later (minutes? hours? I'm not sure) it won't play until you have clicked in the window. This seems to be associated with the start time of the video, not with how long the video had been stopped.

This is fine.

Let's say there's someone with 35,000 hours of DJ sets and live performances spanning 23 years and they would like to run a batch-mode Shazam on them to extract the song names. Is that yet an achievable goal?

If you are about to recommend a tool that you have never used, I implore you to refrain.

Previously, previously.]]> https://cdn.jwz.org/blog/2024/06/bulk-song-id-2/feed/ 26 https://www.jwz.org/blog/2024/01/ascii-dot-theater/ https://www.jwz.org/blog/2024/01/ascii-dot-theater/#comments Tue, 30 Jan 2024 21:44:36 +0000 https://jwz.org/b/ykL3 % ssh watch.ascii.theater

Previously, previously, previously, previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2024/01/ascii-dot-theater/feed/ 9 https://www.jwz.org/blog/2024/01/i-am-not-in-fact-your-music-library/ https://www.jwz.org/blog/2024/01/i-am-not-in-fact-your-music-library/#comments Fri, 19 Jan 2024 20:33:16 +0000 https://jwz.org/b/ykLO Dear Lazyweb, any idea what bullshit Chrome extension keeps trying to load URLs on my site of the form:

/user/DNA_lounge/library/music/Ryoji+Ikeda /user/DNA_lounge/library/music/She+Wants+Revenge /user/DNA_lounge/library/music/Elefant/_/Bokkie /user/DNA_lounge/library/music/Interpol/_/Slow+Hands /user/DNA_lounge/library/music/Alva+Noto /user/DNA_lounge/listening-report/week /user/DNA_lounge/listening-report/year /user/DNA_lounge/listening-report/week /user/DNA_lounge/obsessions

I don't think this is a botnet, but maybe it is? I'm getting a ton of them from (possibly) otherwise legit-seeming IPs reporting plausible and modern Windows Chrome user agents, so I'm hesitant to just fail2ban them all.

Is that what Spotify URLs are shaped like? This is a question that no search engine can answer.

Previously, previously.]]> https://cdn.jwz.org/blog/2024/01/i-am-not-in-fact-your-music-library/feed/ 25 https://www.jwz.org/blog/2024/01/twitch/ https://www.jwz.org/blog/2024/01/twitch/#comments Wed, 10 Jan 2024 19:23:49 +0000 https://jwz.org/b/ykIq

The only Twitch that I acknowledge.

And gosh, I'm all broken up about it. Here, let me re-post something I wrote about Twitch back in 2020, when they were having their moment in the sun due to the lockdown:

Do Zoom next.

Previously, previously, previously, previously, previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2024/01/twitch/feed/ 15 https://www.jwz.org/blog/2023/12/13255155/ https://www.jwz.org/blog/2023/12/13255155/#comments Thu, 28 Dec 2023 21:04:33 +0000 https://jwz.org/b/ykHz Conversations I still have in this, the year Twenty Twenty Three, with the Absolutely Deranged:

Me:	Have you seen [SHOW]? It's really good!
Them:	That does sound really good. What service is it on?
Me:	How the fuck should I know?
Them:	*Taps at phone* Oh, it is not on one of the 7 streaming services I pay for. I guess I shall not watch this show.
Me:	You are a grown-assed adult. You type [SHOW] into Pirate Bay, click first link, receive candy.
Them:	But that sounds harrrrrrrrrrd.

Make your New Year's resolution be to stop being That Guy.

Previously.]]> https://cdn.jwz.org/blog/2023/12/13255155/feed/ 56 https://www.jwz.org/blog/2023/11/window-open/ https://www.jwz.org/blog/2023/11/window-open/#comments Wed, 15 Nov 2023 04:39:53 +0000 https://jwz.org/b/ykGN Dear Lazyweb,

Some time recently, my function that opens a player window for the DNA Lounge webcast stopped opening the window in a custom size and with toolbars hidden. In Safari 17.1, it opens it as a default-sized window; in Chrome 114 it opens it as a tab; and in Firefox 114 it does the old thing that it is supposed to do.

How fix? See function dna_video_player in webcast.js.

Previously, previously.]]> https://cdn.jwz.org/blog/2023/11/window-open/feed/ 5 https://www.jwz.org/blog/2023/07/detecting-corrupted-mpeg-audio/ https://www.jwz.org/blog/2023/07/detecting-corrupted-mpeg-audio/#comments Wed, 19 Jul 2023 23:49:27 +0000 https://jwz.org/b/ykBK Dear Lazyweb, here is a TS fragment with spectacularly corrupted audio. Is there some way to get ffmpeg or similar to tell me, "Yup, that's fucked"?

I poked around with ffprobe hoping I'd see, like, weird bitrates or something, but I'm not even sure what I'm looking for.

This corruption sometimes happens when OBS is reading both audio and video from the new Kiloview NDI encoder. It is usually accompanied by corrupted video, but after the video clears up, the audio stays in this weird state forevermore until OBS re-opens the stream. But to automate that, I need to be able to detect the error state. From a shell script, not with my ears.

My only other option is to go back to reading video from the NDI and audio from line-in, but then they are desynchronized by several seconds. I could add an empirical audio delay in OBS, but it's not obvious to me that the required delay will be constant.

Any ideas?

Previously.]]> https://cdn.jwz.org/blog/2023/07/detecting-corrupted-mpeg-audio/feed/ 24 https://www.jwz.org/blog/2023/07/webcast-help/ https://www.jwz.org/blog/2023/07/webcast-help/#comments Tue, 04 Jul 2023 03:22:35 +0000 https://jwz.org/b/ykAw Dear Lazyweb,

Our webcast setup is incredibly flaky and it has proven to be beyond our ability to diagnose and fix. Further, everyone here absolutely hates dealing with it: "Go figure out why camera 7 has no signal". "I looked at it sternly and now it seems fine again for now?" It is not rewarding.

I would like to hire someone to Make It Go.

I suspect at this point we just have to work down the list:

• Did you replace the BNC connectors on every SDI coax cable?
• Did you use high-quality connectors, not loose, wobbly, counterfeit Chinese junk? Are you sure?
• Did you re-run the cable? Spoiler alert, the answer is no because there are miles of it and that sucks.

So I'd like to hire someone with experience installing and diagnosing SDI cameras, particularly for the annoying "re-run miles of cable" part. Maybe someone who owns and knows how to operate relevant test equipment.

I am aware that the problem with hiring someone who knows what they're doing is that their experience is likely to be, "Well, when I did the installation for 50 conference rooms at a convention center, the first thing we did was buy cameras at $5k a pop, and a $90k video switcher, also there's a tech on site at all times, nothing ever runs unattended". So they may not be experientially amenable to my dive-bar IT department budget of "concert tickets and free beer". Fortunately, though, several people who sound like they know what they're talking about tell us that for the things we're trying to do, and the distances involved, SDI "should" work "just fine", so why we have to much trouble is a mystery.

If you want to volunteer, that's great too, I'll take it. But if I pay someone, then I get to say, "Hey, you said it was fixed and it's not."

Any suggestions for how to find this person?

And for those of you who are not inclined to crawl around in the rafters pulling cable... Just a reminder that our webcast -- which has been broadcasting 24/7 for two decades, and is at this point probably the oldest continuously-operating video stream in the world -- earns us zero dollars. Negative dollars, really. So if it is a thing that you enjoy (or dare we dream, would like to see improved) feel free to kick in a donation...

Previously, previously.]]> https://cdn.jwz.org/blog/2023/07/webcast-help/feed/ 13 https://www.jwz.org/blog/2023/04/brb-upgrading-the-webcast/ https://www.jwz.org/blog/2023/04/brb-upgrading-the-webcast/#comments Tue, 04 Apr 2023 03:37:12 +0000 https://jwz.org/b/yj_C

Previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2023/04/brb-upgrading-the-webcast/feed/ 1 https://www.jwz.org/blog/2023/02/audio-hijack-fuckery/ https://www.jwz.org/blog/2023/02/audio-hijack-fuckery/#comments Mon, 13 Feb 2023 19:34:27 +0000 https://jwz.org/b/yj98 Dear Lazyweb, do you recognize the error "The output device Loopback Audio does not appear to be attached to your Mac"?

That device is indeed no longer listed in Audio Hijack or in system sound preferences.

This is a macOS 10.15.7 Mini that had been working fine until a couple days ago. I haven't intentionally made any changes recently so I don't know what melted. I tried re-downloading Loopback, re-installing ACE, upgrading to Audio Hijack 4.1.1, and rebooting. Same.

I mailed Rogue Amoeba support yesterday, who are usually good about these things, but they haven't responded yet and I'd really like to have this fixed before... 8pm.

Update: Fixed. Turns out there was a "turn it off and then on again" checkbox that I had bonked before rebooting that also wanted a bonk after.

Previously, previously, previously.]]> https://cdn.jwz.org/blog/2023/02/audio-hijack-fuckery/feed/ 2 https://www.jwz.org/blog/2022/11/blunderbolt/ https://www.jwz.org/blog/2022/11/blunderbolt/#comments Sat, 19 Nov 2022 03:55:22 +0000 https://jwz.org/b/yj6j Dear Lazyweb,

I want a Thunderbolt 3 hub with these properties:

1. Can run video through it.
2. Externally powered.
3. When external power is cut, connected devices lose power, rather than continuing to be powered by the host.

Does this exist?

The goal here is not "be a hub" but "be able to power cycle the device", since my piece of shit Blackmagic UltraStudio Recorder 3G often loses its mind and stops functioning unless I physically unplug it from the Thunderbolt cable and re-plug it.

Rebooting the host computer is not an option, and I can think of no other way to remotely reset this piece of shit, since it is powered from the Thunderbolt cable, not an external power supply.

But I do have a PDU that lets me remotely cycle plug sockets.

Previously.]]> https://cdn.jwz.org/blog/2022/11/blunderbolt/feed/ 22 https://www.jwz.org/blog/2022/10/jwz-mixtapes-15th-anniversary/ https://www.jwz.org/blog/2022/10/jwz-mixtapes-15th-anniversary/#comments Thu, 20 Oct 2022 19:22:25 +0000 https://jwz.org/b/yj5l 15 years ago today, I posted jwz mixtape ØØ1, the first in a series of at-the-time weekly and audio-only 90 minute chunks of music. To commemorate, I have re-enabled all of the old audio-only mixtapes for two weeks.

Scroll down. Farther. Farther. Keep going. No, scroll down really far. There it is.

In the early days, the theme was "music I have been enjoying this week", so it wasn't necessarily new stuff, though I did try to make them flow together well. Occasionally I would do a mixtape with a secret or not-so-secret "what's the connection?" theme, like "songs with Control in the title" or "songs whose titles are 4 character acronyms."

I kept up the nearly-weekly pace for a few years, through mixtape Ø75, running out of steam in early 2009. That's when I switched to the new format of video-only mixtapes, containing only new music. I've managed to keep up the nearly-monthly pace ever since.

Since mixtape 237 isn't full yet, enjoy the ancient history!

Notes:

1. Track names aren't displaying in the popup audio player because things have atrophied somewhat in the intervening decades. Oh well. Make due. Update: Ok, maybe I've fixed that.

2. Many of the video-only mixtapes are missing up to 30% of their songs, because they vanished out from under me on YouTube at the fickle whims of the Content Mafia, and keeping track of those shifting sands proved to be far too much work. I tried for a while, but it was hopeless. As Textfiles often says, "YouTube is a video archive in the same sense that a supermarket is a Food Museum."

I have several Blackmagic MiniRecoder SDI → Thunderbolt dinguses. Every now and then they lose their minds and stop producing video unless unplugged and re-plugged.

Two questions:

1. How can I reset it without physical access? Is there some way to reset the whole thunderbolt bus, or to power-cycle all devices attached to it?

   I have also noticed that sometimes it gets weirdly finicky about the cab.e Sometimes reversing the cable is necessary to make it work again. I have a stack of these fucking cables, some brand new, and sometimes one works and another doesn't; and then they trade, and the old one is the only one that will work.

2. How can I detect the thing having gone into the bad state?

   When it is in the bad state, the "Blackmagic Desktop Video / Desktop Video Setup" app consistently says "No desktop video device connected" rather than listing the device name. So what I want to know is, how do I get that status result from a command line tool?

   When it is in the bad state, "system_profiler SPThunderboltDataType -json" still lists the device. At some point I had believed that if link_status_key was 0x1 or 0x2, things were good, otherwise they were bad, but that is not good enough, apparently, since right now I'm seeing 0x2 but it's not working.

   Here's the output on a Mac mini i5, 10.15.7, with a MiniRecorder in a working state:

   {
     "SPThunderboltDataType" : [
       {
         "_items" : [
           {
             "_name" : "UltraStudio Mini Recorder",
             "device_id_key" : "0xA129",
             "device_name_key" : "UltraStudio Mini Recorder",
             "device_revision_key" : "0x1",
             "receptacle_upstream_ambiguous_tag" : {
               "cm_asn_key" : "C4M050204F5F797AG",
               "cm_version_key" : "1.0.16",
               "current_speed_key" : "Up to 10 Gb/s x1",
               "link_status_key" : "0x2",
               "pm_version_key" : "0.2.5",
               "receptacle_status_key" : "receptacle_connected"
             },
             "route_string_key" : "1",
             "switch_uid_key" : "0x0004000000130970",
             "switch_version_key" : "7.2",
             "vendor_id_key" : "0x4",
             "vendor_name_key" : "Blackmagic Design"
           }
         ],
         "_name" : "thunderbolt_bus",
         "device_name_key" : "Mac mini",
         "domain_uuid_key" : "73874C54-62C9-C753-BD76-E1EA186DD0DD",
         "receptacle_1_tag" : {
           "cm_asn_key" : "C4M050204F5F797AG",
           "cm_version_key" : "1.0.16",
           "current_speed_key" : "Up to 10 Gb/s x1",
           "lc_version_key" : "0.12.3",
           "link_status_key" : "0x2",
           "receptacle_id_key" : "1",
           "receptacle_status_key" : "receptacle_connected"
         },
         "route_string_key" : "0",
         "switch_uid_key" : "0x0001000D194BC520",
         "switch_version_key" : "23.4",
         "vendor_name_key" : "Apple Inc."
       }
     ]
   }

   And here it is on a Mac mini i7, 12.6, with a MiniRecorder in the bad state:

   {
     "SPThunderboltDataType" : [
       {
         "_items" : [
           {
             "_name" : "UltraStudio Mini Recorder",
             "device_id_key" : "0xA129",
             "device_name_key" : "UltraStudio Mini Recorder",
             "device_revision_key" : "0x1",
             "mode_key" : "thunderbolt_one",
             "receptacle_upstream_ambiguous_tag" : {
               "cm_asn_key" : "C4M310400W1F798A5",
               "cm_version_key" : "1.0.16",
               "current_speed_key" : "Up to 10 Gb/s x1",
               "link_status_key" : "0x2",
               "pm_version_key" : "0.2.5",
               "receptacle_status_key" : "receptacle_connected"
             },
             "route_string_key" : "3",
             "switch_uid_key" : "0x00040000001FD690",
             "switch_version_key" : "7.2",
             "vendor_id_key" : "0x4",
             "vendor_name_key" : "Blackmagic Design"
           }
         ],
         "_name" : "thunderbolt_bus",
         "device_name_key" : "Mac mini",
         "domain_uuid_key" : "C6AAD605-5E79-5159-B46F-80B40E12FDBA",
         "receptacle_1_tag" : {
           "current_link_width_key" : "0x1",
           "current_speed_key" : "Up to 20 Gb/s x1",
           "lc_version_key" : "0.14.0",
           "link_status_key" : "0x7",
           "receptacle_id_key" : "1",
           "receptacle_status_key" : "receptacle_no_devices_connected"
         },
         "receptacle_2_tag" : {
           "cm_asn_key" : "C4M310400W1F798A5",
           "cm_version_key" : "1.0.16",
           "current_link_width_key" : "0x1",
           "current_speed_key" : "Up to 10 Gb/s x1",
           "lc_version_key" : "0.14.0",
           "link_status_key" : "0x2",
           "receptacle_id_key" : "2",
           "receptacle_status_key" : "receptacle_connected"
         },
         "route_string_key" : "0",
         "switch_uid_key" : "0x000100150242A160",
         "switch_version_key" : "26.1",
         "vendor_name_key" : "Apple Inc."
       }
     ]
   }

Previously, previously, previously.]]> https://cdn.jwz.org/blog/2022/09/thunderbolt/feed/ 25 https://www.jwz.org/blog/2022/03/crontab/ https://www.jwz.org/blog/2022/03/crontab/#comments Mon, 14 Mar 2022 17:48:08 +0000 https://jwz.org/b/yjya echo REBOOT     ...]]> crontab(5):

Instead of the first five fields, one of eight special strings may appear:

string	meaning
@reboot	Run once, at startup.

Me: Hmm, I wonder if that actually works:

% crontab -l
@reboot   echo REBOOT

crond:

Cron Daemon     Cron <root> echo REBOOT     8:46:54 AM
Cron Daemon     Cron <root> echo REBOOT     8:47:24 AM
Cron Daemon     Cron <root> echo REBOOT     8:48:35 AM
Cron Daemon     Cron <root> echo REBOOT     8:48:37 AM
Cron Daemon     Cron <root> echo REBOOT     8:48:48 AM
Cron Daemon     Cron <root> echo REBOOT     8:48:58 AM
Cron Daemon     Cron <root> echo REBOOT     8:49:59 AM
Cron Daemon     Cron <root> echo REBOOT     8:49:59 AM
Cron Daemon     Cron <root> echo REBOOT     8:49:59 AM
Cron Daemon     Cron <root> echo REBOOT     8:50:20 AM
Cron Daemon     Cron <root> echo REBOOT     8:50:31 AM
Cron Daemon     Cron <root> echo REBOOT     8:54:06 AM
Cron Daemon     Cron <root> echo REBOOT     8:54:06 AM
Cron Daemon     Cron <root> echo REBOOT     8:54:06 AM
Cron Daemon     Cron <root> echo REBOOT     8:54:06 AM
Cron Daemon     Cron <root> echo REBOOT     8:54:26 AM
Cron Daemon     Cron <root> echo REBOOT     8:54:39 AM
Cron Daemon     Cron <root> echo REBOOT     8:55:22 AM
Cron Daemon     Cron <root> echo REBOOT     8:56:11 AM
Cron Daemon     Cron <root> echo REBOOT     8:56:50 AM
Cron Daemon     Cron <root> echo REBOOT     8:57:46 AM
Cron Daemon     Cron <root> echo REBOOT     8:58:32 AM
Cron Daemon     Cron <root> echo REBOOT     8:59:16 AM
Cron Daemon     Cron <root> echo REBOOT     9:00:03 AM
Cron Daemon     Cron <root> echo REBOOT     9:00:55 AM
Cron Daemon     Cron <root> echo REBOOT     9:02:03 AM
Cron Daemon     Cron <root> echo REBOOT     9:02:42 AM
Cron Daemon     Cron <root> echo REBOOT     9:03:35 AM
Cron Daemon     Cron <root> echo REBOOT     9:04:27 AM
Cron Daemon     Cron <root> echo REBOOT     9:05:13 AM
Cron Daemon     Cron <root> echo REBOOT     9:06:05 AM
Cron Daemon     Cron <root> echo REBOOT     9:06:48 AM
Cron Daemon     Cron <root> echo REBOOT     9:07:35 AM
Cron Daemon     Cron <root> echo REBOOT     9:08:23 AM
Cron Daemon     Cron <root> echo REBOOT     9:09:07 AM
Cron Daemon     Cron <root> echo REBOOT     9:09:52 AM
Cron Daemon     Cron <root> echo REBOOT     9:10:35 AM
Cron Daemon     Cron <root> echo REBOOT     9:11:28 AM
Cron Daemon     Cron <root> echo REBOOT     9:12:20 AM
Cron Daemon     Cron <root> echo REBOOT     9:13:17 AM
Cron Daemon     Cron <root> echo REBOOT     9:14:00 AM
Cron Daemon     Cron <root> echo REBOOT     9:15:00 AM
Cron Daemon     Cron <root> echo REBOOT     9:15:49 AM
Cron Daemon     Cron <root> echo REBOOT     9:16:40 AM
Cron Daemon     Cron <root> echo REBOOT     9:17:28 AM
Cron Daemon     Cron <root> echo REBOOT     9:18:21 AM
Cron Daemon     Cron <root> echo REBOOT     9:19:08 AM
Cron Daemon     Cron <root> echo REBOOT     9:19:54 AM
Cron Daemon     Cron <root> echo REBOOT     9:20:37 AM
Cron Daemon     Cron <root> echo REBOOT     9:21:36 AM
Cron Daemon     Cron <root> echo REBOOT     9:22:32 AM
Cron Daemon     Cron <root> echo REBOOT     9:23:01 AM
Cron Daemon     Cron <root> echo REBOOT     9:23:54 AM
Cron Daemon     Cron <root> echo REBOOT     9:24:38 AM
Cron Daemon     Cron <root> echo REBOOT     9:25:18 AM
Cron Daemon     Cron <root> echo REBOOT     9:26:11 AM
Cron Daemon     Cron <root> echo REBOOT     9:27:00 AM
Cron Daemon     Cron <root> echo REBOOT     9:27:52 AM
Cron Daemon     Cron <root> echo REBOOT     9:28:43 AM
Cron Daemon     Cron <root> echo REBOOT     9:29:32 AM
Cron Daemon     Cron <root> echo REBOOT     9:30:29 AM
Cron Daemon     Cron <root> echo REBOOT     9:31:18 AM
Cron Daemon     Cron <root> echo REBOOT     9:32:18 AM
Cron Daemon     Cron <root> echo REBOOT     9:33:13 AM
Cron Daemon     Cron <root> echo REBOOT     9:33:34 AM

% uptime
10:43 up 1:09, 6 users, load averages: 5.57 5.49 5.42

Update: It happened again to one of my other machines! Check this shit out! I have no idea why this machine rebooted. It was not a power failure, and system.log provides no clues. This time the cron job was "date; uptime". Several hours after this happened, it reported:

% date; uptime
Wed Mar 16 09:39:03 PDT 2022
9:39 up 6:25, 3 users, load averages: 2.41 2.35 2.33

Wed Mar 16 02:58:09 PDT 2022   2:58 up 28 days, 1:33, 2 users, load averages: 19.27 6.28 3.99
Wed Mar 16 02:58:09 PDT 2022   2:58 up 28 days, 1:33, 2 users, load averages: 19.27 6.28 3.99
Wed Mar 16 02:59:43 PDT 2022   2:59 up 28 days, 1:34, 2 users, load averages: 129.46 54.89 23.51
Wed Mar 16 03:01:53 PDT 2022   3:01 up 28 days, 1:36, 2 users, load averages: 153.98 98.37 45.77
Wed Mar 16 03:02:58 PDT 2022   3:02 up 28 days, 1:37, 2 users, load averages: 98.98 93.57 47.87
Wed Mar 16 03:03:50 PDT 2022   3:03 up 28 days, 1:38, 2 users, load averages: 154.26 108.06 56.02
Wed Mar 16 03:04:02 PDT 2022   3:04 up 28 days, 1:38, 2 users, load averages: 189.32 118.11 60.52
Wed Mar 16 03:04:15 PDT 2022   3:04 up 28 days, 1:39, 2 users, load averages: 204.15 123.68 63.17
Wed Mar 16 03:04:20 PDT 2022   3:04 up 28 days, 1:39, 2 users, load averages: 202.53 124.68 63.88
Wed Mar 16 03:04:32 PDT 2022   3:04 up 28 days, 1:39, 2 users, load averages: 195.38 125.66 64.93
Wed Mar 16 03:04:40 PDT 2022   3:04 up 28 days, 1:39, 2 users, load averages: 186.21 126.01 65.76
Wed Mar 16 03:04:52 PDT 2022   3:04 up 28 days, 1:39, 2 users, load averages: 158.03 121.96 65.03
Wed Mar 16 03:05:02 PDT 2022   3:05 up 28 days, 1:39, 2 users, load averages: 138.29 118.89 64.60
Wed Mar 16 03:05:12 PDT 2022   3:05 up 28 days, 1:40, 2 users, load averages: 117.26 115.02 63.87
Wed Mar 16 03:05:56 PDT 2022   3:05 up 28 days, 1:40, 2 users, load averages: 137.33 120.70 68.60
Wed Mar 16 03:06:05 PDT 2022   3:06 up 28 days, 1:41, 2 users, load averages: 152.45 124.53 70.57
Wed Mar 16 03:06:20 PDT 2022   3:06 up 28 days, 1:41, 2 users, load averages: 165.60 128.75 73.02
Wed Mar 16 03:06:27 PDT 2022   3:06 up 28 days, 1:41, 2 users, load averages: 163.87 129.00 73.43
Wed Mar 16 03:06:36 PDT 2022   3:06 up 28 days, 1:41, 2 users, load averages: 149.93 127.09 73.40
Wed Mar 16 03:06:36 PDT 2022   3:06 up 28 days, 1:41, 2 users, load averages: 149.93 127.09 73.40
Wed Mar 16 03:06:56 PDT 2022   3:06 up 28 days, 1:41, 2 users, load averages: 129.17 123.51 73.34
Wed Mar 16 03:07:56 PDT 2022   3:07 up 28 days, 1:42, 2 users, load averages: 137.78 125.27 77.33
Wed Mar 16 03:08:24 PDT 2022   3:08 up 28 days, 1:43, 2 users, load averages: 165.72 133.16 81.59
Wed Mar 16 03:08:44 PDT 2022   3:08 up 28 days, 1:43, 2 users, load averages: 153.51 132.50 82.82
Wed Mar 16 03:10:08 PDT 2022   3:10 up 28 days, 1:45, 2 users, load averages: 134.03 132.19 87.21
Wed Mar 16 03:10:08 PDT 2022   3:10 up 28 days, 1:45, 2 users, load averages: 134.03 132.19 87.21
Wed Mar 16 03:10:08 PDT 2022   3:10 up 28 days, 1:45, 2 users, load averages: 134.03 132.19 87.21
Wed Mar 16 03:10:38 PDT 2022   3:10 up 28 days, 1:45, 2 users, load averages: 103.43 125.11 86.21
Wed Mar 16 03:10:48 PDT 2022   3:10 up 28 days, 1:45, 1 user, load averages: 87.91 121.07 85.23
Wed Mar 16 03:11:16 PDT 2022   3:11 up 28 days, 1:46, 1 user, load averages: 64.13 112.71 83.25
Wed Mar 16 03:11:37 PDT 2022   3:11 up 28 days, 1:46, 1 user, load averages: 51.50 105.89 81.64
Wed Mar 16 03:11:49 PDT 2022   3:11 up 10 secs, 0 users, load averages: 2.62 0.56 0.20
Wed Mar 16 03:12:19 PDT 2022   3:12 up 28 days, 1:47, 1 user, load averages: 29.12 93.42 78.19
Wed Mar 16 03:12:19 PDT 2022   3:12 up 28 days, 1:47, 1 user, load averages: 29.12 93.42 78.19
Wed Mar 16 03:12:41 PDT 2022   3:12 up 28 days, 1:47, 1 user, load averages: 23.51 87.95 76.58
Wed Mar 16 03:13:13 PDT 2022   3:13 up 28 days, 1:48, 1 user, load averages: 23.12 80.66 74.38
Wed Mar 16 03:13:35 PDT 2022   3:13 up 28 days, 1:48, 1 user, load averages: 17.13 75.56 72.70

So my "@reboot" job ran 37 times over the course of 8½ minutes BEFORE the machine rebooted, and then zero times after.

That's... super helpful. really just super helpful.

Previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2022/03/crontab/feed/ 16 https://www.jwz.org/blog/2021/08/nginx-404-handling-hls-shenanigans-part-2/ https://www.jwz.org/blog/2021/08/nginx-404-handling-hls-shenanigans-part-2/#comments Sat, 14 Aug 2021 22:10:57 +0000 https://jwz.org/b/yjpi

I have an "infinite colorbars video stream" working now, I think. Does it work for you on your various devices? Video stream is embedded above, source. "Works" means "continues playing looping colorbars for longer than two minutes."

Second problem is, how do I get nginx to redirect to this when an index.m3u8 file goes 404? I tried this and it is not working:

location ~ index\.m3u8$ {
  error_page 404 https://videocdn.dnalounge.com/video404/index.m3u8;
}

Under normal circumstances, nginx is filling up /var/run/hls/live/ with several .ts files and a single index.m3u8 file. When the source disconnects, the .ts files expire one by one, and when none are left, the .m3u8 file and the the enclosing directory, /var/run/hls/live/ also disappear. So maybe that's causing problems with the 404 handler?

Update: I got the 404 handling working. The file /live.m3u8 normally contains a list of the two sub-streams, a full and a downcoded version. But when it would have gone 404, it instead contains the contents of /video404/index.m3u8, which is the looping colorbars. But, it doesn't really work. First, the transition from "video" to "colorbars" is not immediate; one has to click play again, which kind of defeats the purpose. And second, the transition back from colorbars never happens! The colorbars just keep playing on a loop forever (until one hits reload), even after /live.m3u8 no longer has colorbars in it.

So, it was a long shot, and everything sucks.

(And yeah, apparently no browsers except Safari support .m3u8 files natively; it only works if the VIDEO element is wrapped in videojs witchcraft as I do on the webcast page. Here it is by itself.)

Previously, previously, previously.]]> https://cdn.jwz.org/blog/2021/08/nginx-404-handling-hls-shenanigans-part-2/feed/ 27 https://www.jwz.org/blog/2021/08/mtv-turns-40-today-so-thanks-for-14-years-of-music/ https://www.jwz.org/blog/2021/08/mtv-turns-40-today-so-thanks-for-14-years-of-music/#comments Sun, 01 Aug 2021 17:28:01 +0000 https://jwz.org/b/yjpN DNA Lounge webcast with the DNA Pizza music video collection. One does what one can.

Music videos from this era are mostly unobtainium, at any reasonable level of quality. If you're lucky, a handful of them showed up on a long-out-of-print SD DVD compilation release in the early 90s, but generally all that is available are Nth generation VHS rips. If any of you have access to cardboard boxes of the original U-matic tapes of the MTV vault, let me know. I'll launder that shit for you.

Also, I would be remiss in not pointing out that, all dunking on MTV's decades-long irrelevance aside, we are living through the Golden Age of Music Video right now. Three years ago, on the occasion of my 200th mixtape, I did a mixtape of The Greatest Music Videos Of All Time, and in that post I said:

My first draft of this mixtape was seven hours long, and it still felt woefully incomplete.

Though I will eagerly argue that Russell Mulcahy both invented the music video and closed the book on the genre, if you were to make that claim, I'd be quick to tell you how wrong you were and point out that we are absolutely living in the golden age of the music video right now. The accessibility of the tools of production and distribution was supposed to transform the music industry into this cornucopia of new voices, and it so, so did not -- the corporations locked that shit down tight. But for music videos... it kinda did... These days a band with $10k can put together a video that is every bit as high quality and insane as something that in the 80s or 90s would have taken $10M and a crew of 80, and that's not just some tech-cheerleader cliché, small bands are actually doing that and it's amazing.

"Ladies and Gentlemen. Rock and roll."

The goal here is so that when there's a network glitch, the user doesn't have to hit reload, it will just come back to life eventually. (I have tried accomplishing this on the client-side with various Javascript tricks, but the browsers' autoplay restrictions and the general shittiness of the <VIDEO> element conspire to make that mostly impossible.)

Phase 1 might be to convert a 404 on "/live.m3u8" to an internal redirect to a static HLS directory of colorbars. Maybe "try_files" could do this. But phase 2 would be to make the video loop, and a static m3u8 file can't do that. So something would have to fake up an m3u8 with new timestamps on the old TS files, I guess?

Previously, previously.]]> https://cdn.jwz.org/blog/2021/07/nginx-hls-shenanigans/feed/ 9 https://www.jwz.org/blog/2021/04/look-upon-my-obs-hell-and-despair/ https://www.jwz.org/blog/2021/04/look-upon-my-obs-hell-and-despair/#comments Mon, 26 Apr 2021 17:35:21 +0000 https://jwz.org/b/yjni So, you just wanna stream 24/7, and occasionally switch input on a timer? How hard could that be?

For your amusement, read the comments in the ~2000 line sh script that keeps DNA Lounge running.

Here be monsters.

When I say that almost all of my coding stems from either self defense or spite, this is what I mean.

Previously, previously, previously, previously.]]> https://cdn.jwz.org/blog/2021/04/look-upon-my-obs-hell-and-despair/feed/ 20 https://www.jwz.org/blog/2021/03/atem-control/ https://www.jwz.org/blog/2021/03/atem-control/#comments Thu, 01 Apr 2021 02:14:31 +0000 https://jwz.org/b/yjm2 As far as I can tell, the control protocol is undocumented binary UDP, only partially reverse-engineered. They have a so-called SDK but the documentation is a slide deck whose most informative page starts with "Create a Visual Studio project..."

I see a bunch of things on Github (and none on CPAN) but I can't tell what most of them even purport to do. So I'm not asking you to google it for me, I would like to know if you have actually done this thing.]]> https://cdn.jwz.org/blog/2021/03/atem-control/feed/ 6 https://www.jwz.org/blog/2020/12/yule-be-shocked-by-this-outcome-im-sure/ https://www.jwz.org/blog/2020/12/yule-be-shocked-by-this-outcome-im-sure/#comments Sun, 27 Dec 2020 00:41:29 +0000 https://jwz.org/b/yjiN DNA Lounge Yule Log stream? Of course you do.

Welp. For laughs, I uploaded it to YouTube, even though I knew it wouldn't work -- since they now limit videos to 12 hours, it's in two parts, both blocked. This may be a record, earning a total of 326 Content-ID blockages! Out of 406 songs on the playlist, 52% resulted in "video cannot be seen" and 80% resulted in "video cannot be monetized".

BUT! Santa's ever-vigilant little helpers, those eager elves known as Archive dot org, have hidden a copy of it inside their hollow tree:

In conclusion, Google hates Christmas.

Enjoy the video. And please buy some DNA Lounge merch or pizza and booze. It's what Santa would do, and Krampus too.