I think it's just a pretty consolidated space? Kind of like ebook management, which was dominated by Calibre for so many years (this changed recently).
But unlike ebooks, media centre management is a fair bit more complex since it involves supporting many different media formats and many forms of acceleration or transcoding.
So the big projects - Kodi for local media and Jellyfin for streaming - have a lot of inertia because they tend to support whatever you throw at them.
Until a year ago, it was either Calibre/CalibreWeb, Audiobookshelf, or a few alternative readers heavily focused on comics.
Late last year, a vibe-coded app called BookLore appeared and basically brought over everything Calibre did but with much better UX and e-reader integration. The original dev crashed out[0], but the community picked up the project and started reigning in the worst of the slop and maintaining it as Grimmory [1]. It's pretty damn good.
There is also a book fetcher called Shelfmark [2] that integrates with Calibre, ABS, or Grimmory.
[0] and he _might_ be currently trying to push another even more vibe-coded competitor, but that's unconfirmed drama
It’s not that difficult to be honest. VLC / ffmpeg can do most of the heavy lifting. And there’s no shortage of libraries for rendering in a UI.
There used to be dozens of options to choose from. Multiple different XBMC forks. Multiples different Subsonic forks. Multiple different DNLA servers. Multitudes of web-based servers. CLI MP3 servers. Independent media centres for a variety of different consoles.
Maybe that’s still available and just not indexed on that site. But I noticed the choices had shrank significantly last year when I was looking for Plex alternatives compared with when I last built a media centre approximately 15 years ago.
Maybe smart TVs have reduced people’s desire here?
Sounds easy if all you have to do is write a short comment about it. People who actually did it, like the recently retired lead of the Jellyfin project, didn't make it sound like it's "not that difficult" [1].
If you want ot vibe code a project for yourself it's probably reasonable amount of effort. But if you want to build a product, something with polish, something not held together by spit and scotch tape, something reliable, it won't be easy.
I did write a media centre around 15 years ago. What that link you shared describes is the very real toll that maintaining an open source project demands. Not the specific complexities of transcoding multimedia.
From personal experience, the transcoding was the easy part. Building a UX that was intuitive and a backend that catalogued the media accurately required far more attention.
This is such a weird comment chain. Of course transcoding media is the easy part, ffmpeg exists. Even if it didn't, it would still be the easy part because you're just building computer algorithms that are like specified and defined and testable.
Making something that actually interacts with "the human world" is 100s of times harder than writing any kind of algorithm.
> Even if it didn't, it would still be the easy part because you're just building computer algorithms that are like specified and defined and testable.
I'd challenge that. Have you looked at the specifications of any reasonably current compression standards? The AVC one is some 900 pages, I think.
Entire communities exist around discussing the strengths and shortcomings of different codec implementations.
I would love to see an Open Source media center that supports streaming services. I wouldn't care if the services say "we only support 1080p for browsers / open source, anything more needs a locked-down device". (Perhaps the project could have some add-on you can buy that's a physical hardware dongle for doing 4k HDR and emitting HDCPed HDMI.) I already live with that for watching on my laptop. Just having watchable basic-resolution streaming would make it a one-stop-shop.
If streaming through a browser/open source / not the locked down app supported 1080p I would be a lot happier. My understanding from the last time i looked is that it actually only supports 720p
You can coax Netflix into giving you 1080p in ordinary Firefox by setting the right user-agent. That's good enough for me, and if it stops working I'll be motivated to stop paying those assholes anyway.
The issue is many streaming services require DRM in the browser.
I can’t recall if Chromium supports that, I have a feeling Google only include that DRM in Chrome. But if it is available in Chromium then you might be able to build an Electron app.
I think I understand how to use about 20 of the command line options for ffmpeg and the companion utilities like ffprobe. Which is to say; I understand about 0.5% of the total options they provide and am likely a world leading expert in it. I'm mostly joking -- as in, overstating how many of them I understand.
Understanding ffmpeg borders on a specialization in itself. No big surprise that so many of the alternatives have fallen away over the years as people realize the absolute scope of that piece of software.
You don’t need to understand much of ffmpeg to build a media centre. Your requirements here are extremely simplified and there are hundreds of guides online on how to use it for very simple transcoding.
But if you don’t want to use ffmpeg directly then use one of the many ffmpeg wrappers. Or a different lib entirely like gstreamer or VLC.
Around 15 years ago I built a media centre for my car and the media playback part turned out to be the easiest part of the project.
No. It was built before Android / Apple integrations existed and was built around tactile controls and voice interactions. But I think Apple Car play is a far far more useful product these days than anything I built 15 years ago. Even if their touch controls are an ergonomic step backwards.
i had media center powered by a few perl script that would transcode all videos into formats that ps3 supported in 2007-ish. Yes ffmpeg had a lot of options, 99% of them does not matter, there really only 3 ways to stream to client: as is, repack streams into something client support (i.e. your source is mkv) or transcode into something client support (clients know which formats they support).
People that run these services don't want "dynamic stream quality selection".
> Multiple different XBMC forks. Multiples different Subsonic forks. Multiple different DNLA servers. Multitudes of web-based servers. CLI MP3 servers.
Big difference between _audio_ streaming and _video_ streaming servers. Video streaming is much more complex and pretty consolidated, as I mentioned.
Audio streaming is much more manageable: no issues with transcoding, acceleration or subtitling, and a radically simpler UI. Also ID3 tags aren't great but they're a pretty universal standard with lots of databases, you don't need to desperately scrape IMDB/TMBD for info.
As a result there are quite a few music servers, often exposing Subsonic compatible APIs, ranging from the minimalistic to the 'I'm trying to do everything Spotify does'.
There’s literally no difference in difficulty between audio and video.
They all suffer from the same problems of indexing content. They all have multiple different encoding formats available. And they all need a frontend widget in your client for playback.
I’ve worked with both the audio and video streaming platforms and what you’re describing is grossly inaccurate. The fact that your container format isn’t including video frames doesn’t magically solve any of these issues.
Plus ID3 can be a source of new problems by itself given the way it was implemented…twice.
The answer to every question about how to use/write it is the counter question: well, which software or player do you want it to work with? Here are your 8 mutually incompatible options.
It's logical, but the low variety is disappointing nonetheless and makes it more likely than none of the available options are well-suited to one's needs/desires.
In the case of media management, ffmpeg is easily usable with just about every programming language in existence and its usage is extremely well-trodden at this point, which makes the vacuum of newer alternatives to the XBMC lineage all the more puzzling.
ffmpeg is a beast, not gonna argue that. As another commenter noted however, only a small fraction of those options are necessary to cover a media center project, especially if you're not beholden to supporting esoteric/archaic formats, aren’t bothered with trying to make broken/corrupted files play, etc. Being willing to specialize can also help reduce scope.
> the vacuum of newer alternatives to the XBMC lineage all the more puzzling.
What is there to be puzzled about? Doing media transcoding is the easy part, dealing with humans is the hard part so.. programmers aren't rushing out to do it.
Fair point, for text it is far harder to prevent signatures being applied to generated text vs images at the moment of capture and most approaches I can come up with to remedy this can either be bypassed (edit histories can be output by models similar to humans) or will be controversial. Taking a page out of the anti-cheat textbook, mainly written for gaming, there are methods which might hold in the medium term. Less a fan of kernel level myself, though it might be worth exploring as there has been massive investment by the games industry into making it somewhat robust, but the approach Valve has taken with VACnet could be an inspiration worth exploring that is less invasive into peoples systems. Keystroke analysis, etc. could be relied upon as a basis for signatures, harder to spoof for current day LLMs over generating edit histories.
I will fully admit that at a point in the future, maybe not too soon, models may be trained to bypass that too, at which point we are back where we started. As a skeptic of the extend that capabilities are emergent in LLMs vs specific to training data, I am somewhat hopeful that unless models are specifically trained for evading such human detection solutions, they'd struggle to do so, but it could still end up as a byproduct of improved, lower latency computer use focused training. Not emergent as the term is used in regard to models because that is still output performance improvements clearly traceable to very specific training data, but incidental as the goal of said training data was not to bypass.
For what it's worth, I find human authorship being verifiable to simply be the more crucial problem over watermarking model output, so if research is to focus on one, I'd rather it the former. Maybe both signing human authored content and watermarking LLM output are both only possible in the near term, I hope not but fear it that might be the case. If so, we as a society will have some major challenges ahead (beyond all the ones we'd have anyways).
Alternatively, we could also just start scanning everyones eyeballs...
I've been thinking for a while that all of this is just trying to grasp tighter the last bits of sand escaping between our fingers. The end game, perhaps, is trust. Do you trust or know the source? If you don't, assume it was AI generated. If you do, accept it as authentic based on whatever they disclose, but know that it's possible they aren't being totally honest or were themselves fooled in some way, depending on the context.
Then build our assumptions and how we operate around those trust levels in the digital realm.
Well, the end game is that AI is better at thinking us, and having a human brain involved is a net negative. The goal is to let the AI do the toil if thinking for us, and we can get the rewards.
I tried to switch to nushell full-time but couldn't stick with it.
Ironically, the main friction point were not old-fashioned tools (which `from ssv` usually handled nicely) but the 'new generation' of core CLI tools like eza or fzf. They have really nice visualizations, but they do not output structured data as a middle step, so all the colours and lines only play havoc with nu's parsing.
Since I need to "ls" a lot more often than I need to do data manipulation, the tools won and I went back to zsh. Still keep nu around for the occasional config/data file wrangling though.
It doesn't stop Android Auto from doing whatever with the car data, but it's sandboxed to have no more default privileges than a regular app, so it can be denied access to your phone's data by default (apps, contacts, etc.). Wireless AA will only work if you grant it extra privileges; wired AA does not need them.
You can also "firewall" AA via something like TrackerControl, this would let you block connections to eg. Google Analytics servers without denying network access altogether (which would likely cause AA to stop working). I've only used AA with short-term rentals so I didn't spend too much time exploring these options.
> Beyond that, this is a laptop that is running a really shitty, 'apps only, no you cannot do anything useful with this' operating system. I have an awful lot of complaints about MacOS's relatively restrictive use cases, but it's still at least a General Purpose OS. Android on laptop is very much not.
Android 16+ offers a built-in integrated Linux VM that can be enabled from Developer Mode, and if this[0] third-party site is accurate, "Android on laptop" will have it enabled by default.
So it should not be too different from working on a Windows laptop with WSL2, or on an OSTree distro where you use distroboxes to work with non-sandboxed programs.
(fwiw, I would still refuse to have one of these for personal use because Google is a shameless data robber. Unless someone were to de-google Aluminium like LineageOS and GrapheneOS did for Android, but that would probably take years.)
> It’s such an annoying question because the honest answer is I eat what the locals eat, which is to say the most authentic Japanese cuisine is what you find in a Japanese supermarket. That’s what the people of Japan are actually eating.
Well, that's only true if you also observe what Japanese customers are buying and do your best to mimic their habits.
You could go into any Italian supermarket and fill your cart with weißwurst, avocados, and Camembert cheese - and they're all right there in the meat, fruit, and dairy areas respectively, not in an 'ethnic' corner - but it would be hardly a good representation of what the locals typically eat.
> so something that 95% of the users of Zed will end up doing?
Will they? I downloaded it for a test run, and there was no pressure to create a Zed account. I got the impression that it's something you'd do if you wanted to use their cloud AI services, and I can't really see why you'd want a third party involved instead of just bringing your own subscription to your favourite model.
That's correct. In practice we would often rephrase to avoid the double 'la', not because it's grammatically incorrect but because it is awkward to read (less so in speech). Compare:
French: C'est une citation de De Gaulle.
German: Das ist ein Zitat von Von Neumann.
Both correct, but one would probably add "Charles" or "John" between the two 'de' or 'von' just to break them up.
The cooldown is a defence against malicious actors compromising the release infrastructure.
Having the forge control it half-defeats the point; the attackers who gained permission to push a malicious release, might well have also gained permission to mark it as "urgent security hotfix, install immediately 0 cooldown".
I have not heard anyone seriously discuss that cooldown prevents compromise of the forge itself. It’s a concern but not the pressing concern today.
And no, however compromised packages to the forge happens, that is not the same thing as marking “urgent security hotfix” which would require manual approval from the forge maintainers, not an automated process. The only automated process would be a blackout period where automated scanners try to find issues and a cool off period where the release gets progressively to 100% of all projects that depend on it over the course of a few days or a week.
By "release infrastructure" I didn't mean gain admin access to github.com, I meant gaining the credentials to push out a release of that particular package.
Even in that scenario, having the duress pin option does not make things worse. It's functionally equivalent to smashing the phone, just easier to do with one hand.
i.e. whatever they do to you if you wiped the phone via duress PIN, they would already do to you if you managed to smash the phone.
But unlike ebooks, media centre management is a fair bit more complex since it involves supporting many different media formats and many forms of acceleration or transcoding.
So the big projects - Kodi for local media and Jellyfin for streaming - have a lot of inertia because they tend to support whatever you throw at them.