Share a nixamp channel into a chat and, until today, the card said the name of the server and nothing else. No picture. For a podcast that had the link nixamp.com/?url=...&play=channel:url-6f4152c1590e, the card read "server1", which is true and useless.
0.23.2 fixes the title and gives every channel a picture. 0.23.4, the same evening, covers the one case it missed.
The title was a name versus id bug
nixamp.com titles a share link from what it actually knows, never from the address, so a stranger cannot put words in a preview. What it knew about a server's channels was a list of names. The page, meanwhile, writes share links by channel id. Names never matched ids, so every channel card fell back to the server.
The heartbeat a server sends the directory now carries a lineup next to the names: id, name, whether it is sound or picture, a picture address and a line about it. The directory cleans it like everything else a publisher says. A picture address is http or https or it is nothing.
Where the picture comes from
Four places, tried in order, whichever a channel has.
The site's own thumbnail. A pasted link is resolved by yt-dlp, and its answer already carried the thumbnail and the description. They are kept now, and the channel is started with them.
The sleeve in the file. A podcast MP3 carries its cover as an attached picture. ffprobe already saw it; that is what stopped a podcast being carried as a dead video channel back in 0.19. The probe now notes the sleeve and the file's title, artist and album tags, and ffmpeg reads that one frame out of the head of the file. A channel that was named ep-0412-final.mp3 is now called what the tags call it.
A frame of the picture. For anything with video, the server decodes one JPEG from the channel's own opening boxes and backlog, the same bytes it hands every new listener. Never by opening the source a second time. An IPTV panel that allows one connection per film counts that second connection against the channel and drops it, and I have been bitten by that once already.
And the picture in the playlist. A station started from a p0dcasters playlist.m3u plays anchor.fm episodes that carry no tags and no sleeve at all, so the first three found nothing. The m3u itself writes an #EXTIMG line per episode, and the parser dropped it. It reads them now, and the first picture in the list is the station's. That was 0.23.4, found while checking the very link that started this.
GET /api/channels/<id>/art
serves it: a redirect to the site's picture, or the JPEG. Five crawlers unfurling one link cost one ffmpeg.
What the card carries
og:image and og:image:alt for everybody, and a Twitter card that fits the picture: summary for a square sleeve beside the words, summary_large_image for a frame of video across the card. The description leads with the line about the channel, then where it is live. No picture means no picture tags; a card with an empty image is a broken card.
The server's own page does the same through its listen link, so a link straight to server1.chovy.nixamp.com unfurls too.
HLS cannot carry a picture, the page can
The question that started this was whether the art could ride inside HLS for the iPhone. It cannot, in any way a browser shows. The session-data tag is for master playlists, and Safari shows none of the ID3 inside segments.
What the iPhone lock screen reads is the page's MediaSession metadata. nixamp now sets its artwork to the channel's picture, so the title and the art show on the lock screen whether the channel is playing as fragmented MP4 or as HLS. The same picture sits under the player and in front of each live channel in the directory.
Get it
curl -fsSL https://nixamp.com/install.sh | sh
nixamp update
Source: https://github.com/profullstack/nixamp, PR #156.
Top comments (0)