it probably uses Core Data, a simple “switch” enabling CloudKit.
Did you encounter recently an application/service architected this way?
Can you explain why an instance of Infuse shouldn’t be able to save a copy of its on-device working database to an external source?
1 Like
The list of “what will go wrong” is endless. As we learn from experience, patterns emerge.
While there are other solutions (third-parties or user-provided), Apple hints at what should be done → App Programming Guide for tvOS: iCloud Storage
But when the local storage is so volatile (AppleTV) and your need of storage is important, recreating the database will take not only too much time (like today) but more and more time. I can’t imagine if my Infuse had to catalog my storage instead of simply fetching meta-data from Plex; I’d probably have deleted the app.
1 Like
After reading that over, it seems that Apple wasn’t intending to provide long term storage for large amounts of data on ATV devices at all. Yes, they do have CloudKit, but that seems more for sharing data between users than for storage of large amounts.
I have a few hundred TV shows, including ones like The Red Green Show, with 300 episodes, Supernatural, with 15 seasons, and a number of other shows with over 150 episodes each (like Star Trek: TNG and DS9). While I get it that Firecore could not foresee all that people would use this feature for, considering it’s storing text and image metadata, the thought that users with really large video libraries would be not only heavy users of a program like Infuse, but would likely run into this issue more than once.
That’s going to take a LONG time to rebuild. I wish I could turn off any screenshots or any images other than small ones, but even then, that’s a lot to rebuild and it makes no sense to use storage that the OS devs have said not to use.
I still don’t see why, since Infuse is used for playing videos from devices on the LAN, it can’t use those same devices for storage.
“users” here (this has been expanded: Sharing CloudKit Data with Other iCloud Users | Apple Developer Documentation) is devices which makes a lot of sense (Apple hopes you’ll have many devices ;)) It also makes sense for Infuse where creating the information is “expensive” (cataloguing your media).
Regarding your next two paragraphs, PLEASE invest time in a server (whichever suits you). If you have a NAS that supports any of them, install it there. Otherwise install it on your most always-on computer with a fast-link to your media. At least try. This is the only way forward. It’s not an opinion, the whole computing paradigm revolves around that.
There are inconveniences like having on set of backup per device.
There are problems like backup’ing the data when the user is leaving (ie putting the app in the background) (I don’t think i/tvOS would allow that).
There are nightmares like Infuse managing a database on a remote file storage (you might be playing from an AppleTV across the world), probably supplementing it with some cache. SQLite Over a Network, Caveats and Considerations
1 Like
My video files are on a 17TB RAID. Over 10TB is in use. Unfortunately, that’s a lot of data and expensive in terms of backing up. But I don’t pirate - all my media data is from physical media I buy, so I can re-rip if needed. I have the RAID set up as a SAMBA server and I have another server that serves as the back end for my DVR and a print server. I’m now deciding between Plex and Emby and I have both on that server at the moment, until I decide which one to go with.
I keep functions like servers OFF desktops so they don’t go down when I have to reboot the desktop systems or use CPU time or space on them.
Do you mean per iOS or tvOS device?
Okay, I can see that as an issue, but if the master DB with all the metadata is stored on a LAN device, then there are ways to work with that. If a user shuts down their device, the amount of user data that might be lost is minuscule - basically just how much has been watched since the last write to the NAS (or whatever else Infuse would be using for storage) So that part could be kept on the ATV and written out to the NAS every minute or five. If the device is downloading data during shutdown, again, a model of writing the downloaded data to the long term storage system periodically would minimize data loss.
Since the current model means writing to an ATV, and the data Infuse keeps is on a per-device basis, I don’t see how this is a problem unless they were to change that. I know it’s possible to keep devices synced through iCloud, but that would mean the info that needs updating would be in the iCloud, so I’m still not clear why an external location is an issue.
That’s not a lot 
and I’m surprised regenerating takes time if you have iCloud backups. media backup would be cheap if you had a DAS instead of a NAS (Backblaze).
You are right, I have a Macmini for that.
yes, if you had one set of backups meta-data, that would mean ensuring consistency which is a big deal (that’s one of the reason why db “clients” talk a a db “server” and don’t mess directly with files).
Let’s forget 10s that this would never be reliable. Engineering resources being not infinite (this is not google nor apple and even there…), designing/writing/debugging such a special feature would divest ressources from making Infuse primary’s purpose even greater (because syncing multiples instances on a central filesystem is not Infuse prime feature).
Does this makes sense? Absolutely not. Is there an industry bulletproof solution? Absolutely, a server.
Again, database servers exist (and more specialized db like Jellyfin) because handling a database is HARD. ACID - Wikipedia
If a desktop computer doesn’t qualify as a server, why would one consider an iPhone or worse, an ATV to act as a server? They are clients, the ATV being very lightweight (main difference being 512Gig in my iPhone vs 128Gig in my ATV).
About that, if any of the i/iPad/tvOS devices were capable of being less volatile, we wouldn’t have this discussion: Infuse on the ATV would detect that the cache had been wiped and would recreate it from iCloud (it is SLOW has hell even with iCloud sync) in the background and things would be mostly fine when you opened Infuse.
1 Like
I use the RAID for media storage and the server (now running doing several things) isn’t the only thing using it. Also, the RAID is on SSDs. Part of what I find frustrating is that VLC can read through the directories and list 'em in seconds, but even when I open a directory in Infuse, and I know that particular directory has nothing but subdirectories in it in Infuse, it can take a long time to load. (So long on iOS I stopped using Infuse on my mobile devices.)
It’s these things, along with the current issue, where I’m losing all my metadata and watched file list more than once a week that makes me think Infuse looks slick, but I am having more and more serious questions about what’s under the hood.
I get that a lot of people like Infuse because it doesn’t require a server, like Plex, Emby, or Jelllyfin. I get the desire to not have to do the work for a server, but their current way of handling this is, to say the least, problematic. Considering, though, they do exactly what Apple said not to do, I’d go so far as to say it’s irresponsible.
There are options - a lot. Make an optional server, or a backup option that stores the data to a NAS, or maybe work out a caching system where the watched list is kept in that small space Apple allows on an ATV and use the cache for writes that are eventually written to the NAS.
You’re pointing out the obvious solution is a server. I agree, but I can see their reluctance to use one. Still, making it an OPTION to those with these issues would be the first responsible step in dealing with this.
On the different possible solutions - I don’t know about others, but being able to tell if a video has been watched is more important to me than the metadata. The metadata can be re-downloaded, but no setting (sync or not) keeps my personal data so it can be restored. When that gets stomped as often as it does, there’s no reason for me to count on it or to pay for a subscription or new version when the only features Infuse provides, that VLC does not, don’t work.
VLC deals with files, Infuse deals with media so normal.
I was really late to the server game (I checked the other day, 7/2014). Before that, I had a WD TV Live, an “AppleTV with a USB port for external drives, only running Infuse” so I understand the simplicity you’re talking about. But these were simpler times : local storage, exclusive to the application (if I remember correctly, it had a dot-directory per directory to store its meta data) and it wasn’t doing much.
Today, our media can be 10.000km away, behind a NAT/Firewall, accessed by 2, 5 devices at the same time.
There is little difference between us and Netflix. And as they deal with 20 millions more devices at the same time, you can trust them to implement the cheapest and easiest to operate solutions.
Does their tvOS app writes to a file system? No. Did they create a media server? Yes. Are they competent? Very much!
As indirectly highlighted by someone here, when Sinology offers a media solution for their NAS, they have you install their media server. If THE network filesystem company doesn’t do what you suggest, they must have a really good reason to do this additional work.
That is quite a leap. There is an incomparable difference between a company worth billions of dollars that has over 200 million customers and people using a tvOS app to play media from a Samba share.
This is not really a valid comparison. Synology sells storage servers and media is a common use-case. Naturally, they want to give users tools to make that data useful. However, their solution is a server-side DLNA application. They don’t offer a client-side player like Infuse.
What are you basing that on? Plex uses an SQLite database to keep track of its data and metadata. That means it’s a single file and there is no database application running. It can easily be copied elsewhere.
As I suggested in the past, SQLite is powerful and simple. I don’t see a reason that an app like Infuse couldn’t write its data to SQLite stored on the user’s network storage. In the worst case, it could be stored on the ATV and the file mirrored on the storage server.
They stream media and they have to do it in a cost-effective & low-maintenance way (of course scale is different but scale makes everything worse). And their architecture is close to Plex, not a client that plays with a samba share
It’s called DS Video and it requires Video Station installed on the NAS. Why do you think they went tthough the hassle of writing additional software if a samba share was a good solution?
In addition to having structured meta-data (requiring protocol/server than understands that), media is streamed and to stream, you use streaming protocols delivered by a streaming server.
What you describe is how we did things 15-20 years ago. Things evolve for the better (for example, samba is nor a streaming protocol nor a WAN protocol) and if you look around, hobbyists and FAANG have access to the same technologies.
Yes, sqlite is an embedded database, the code of the database is “merged” with the rest of any application. And that’s fine because there is only one “user” of the database file. This is in no way meant to be a multiple users code. It accommodates some “multi” scenarios (SQLite Frequently Asked Questions) but everyone avoids this pitfall.
Because nobody does that because it doesn’t work: Samba is not a WAN protocol, database code expects fast (you feel the difference with SSD even at home) and permanent storage, etc. And no, “my ATV is the only Infuse client and the ATV and the NAS are connected with 40G Ethernet” is not a use-case. It’s a particular setup.
This is a sand castle and the tide is coming for it.
Not possible. ATV is a lightweight client: when you put Infuse in the background, it doesn’t have the opportunity to save a significant amount of data. When an app uses Core Data which stores locally, tvOS handles the CloudKit replication, not the app.
I realized that I haven’t mentioned why I’m spending time here advocating for “servers”. Yes, I think and know this is for the better but there is an important selfish motive (disclaimer: I don’t know anyone at firecore nor I have interests in these servers or any “interest” of any kind).
Firecore maintainting this “old” way is similar to them supporting iOS5. Do they or are many developers doing this? No. On the verge on iOS17 release, some developers have already announced that they will soon drop support for <17.
They don’t do this because they are bad people but because this is either looking backwards or looking forward (iOS17 brings features that are only avail with 17SDK, AVisionPro is not far). They don’t have an infinite number of devs and the support matrix quickly becomes horrific.
The reality is (sorry James) that Infuse’s roadmap is “slow”. If they had nudged everyone to a server mode while enabling “direct” mode (only coming in 7.7 although the “browsing” experience has been worse than servers’ own apps since the beginning), the cache problem wouldn’t exist.
Infuse secret sauce is not cataloguing, etc. Servers do it WAY better (if only because they are running permanently). It is the formidable UX and the media player. Nothing comes close.
As a user, I want them to focus on the future, on leveraging ios17, supporting server’s latest features & delivering a great AVisionPro app when I’ll get mine (I hope they’ll charge us more for that as current subscription price is too low).
2 Likes
Even when the subdirectory it’s reading is ONLY directories? I have a directory, TVShows, then, in that directory, classifications, like Comedy, Drama, and so on. I have seen Infuse take MINUTES, and I do mean minutes, since it happened often, when I still used Infuse, from when I selected TVShows until the listing of that directory, with something like 8-10 subdirectories in it, showed up on display. And, yes, I timed it. There’s a thread here where I posted about it and included a video where Infuse took over 5 minutes to read a directory of directories. Supposedly it was cleared up and the thread was marked resolved, but within 3-4 weeks, I was having the same issue again.
My frustration is that I am behind CGNAT (I use Starlink for an ISP), so accessing anything on my LAN from outside is a pain. (I’m setting up Tailscale to fix that - tried many options and one of them, PureVPN, even when supposedly 100% uninstalled, has messed up any VPN on this computer.)
From what I get, and this is a LONG thread, so I haven’t read it all, your position is that Infuse should be using a server for saving the data at this point, due to how things have changed over the years. While I’m thinking of storage as another possibility, I get your point. I don’t have the experience or background, though, to know if a server is needed or if Infuse just needs to be able to write to some kind of network share. I think, though, we both agree that storing the data on the ATV, or on a mobile device, is not only no longer a good idea, but a poor one. My feeling is that going against Apple’s explicit directions on this was not just a poor idea, but reckless and irresponsible.
Am I right that your main point about a server (vs storage) is that if you have a SQL server on another device (as opposed to just storage), that takes care of the issues like file locking during access from multiple systems and issues that come up when a program quits at a bad time?
I would think, also, that if this were done, that each device might have its own data, even metadata, in their own file on the network share? That would me duplicate metadata, but would still be better than the current solution. And it seems to me your point about using the server for backup fo the ATV data is a good one - since it’d be easy to get to quickly. I’ve stopped using Infuse at this point and won’t even consider the next version (since I hear it’s subscription based now - and I’m not paying for a program with problems like this one has at this point). As of now, I’m losing my data in Infuse more than once a week. The data is wiped every 5-6 days now, or it was before I stopped using it.
Even if that’s only happening to a few users, it makes Infuse basically VLC with a different interface since it makes the data, especially user data like the watched list, unreliable.
I don’t know how Infuse works (I haven’t seen the code) but with Plex, if you have media 7 layers deep down, it will try to catalogue them. If VLC on ATV is like on i/MacOS, it just browses directories, nothing else so I hope that’s way faster
Please let me know how it goes, I’m so in love with this product. I’m not forcing my kids to access Plex with it but I’m contemplating the possibility.
My position is that the cataloguing part of Infuse comes from the time when Microsoft had “Windows Media Edition” that you would connect to your TV instead of a monitor and use to play movies (it had a remote - same with Mac and Theater Mode - this dates a WHILE back.). The movies would be stored in your hard drive and the software would catalogue and play the movies. Simple.
Today you have multiples “screens” and they reach your media via fiber, trans-oceanic cables and satellites
And you would not change the way you catalogue, send the infos and the media?
- you would have every “screen” catalogue the files? 5 “screens”, 5 times the same task ?
- while in a park, you’d spend part of your 5G plan on cataloguing when all you wanted was to watch one anime ?
- If you had tens of thousands of media, all your “screens” would have a copy of all the meta-data ?
Does any of this makes sense ? I don’t think so.
a) The cataloguing should be done only once, by a “computer” that’s connected with an unmetered permanent high-speed connection.
b) The “screen” should store only enough data to show their UI and then be refreshed with only the needed updated data, like the new “recent media” if that’s what displayed.
c) a long-lived protocol should be used to stream the media over those unreliable links that are in between the “screen” from the media.
To your other points, Infuse is no question an excellent “screen” when used with a media server, the best even. With direct mode coming in 7.7, you’ll be able to use it for what it does best, leaving the “tasks that should be done once and centrally” to a server of your liking. (today even with Plex, data is wiped every 2 days ; recover is fast though.) So don’t give up !
Since a few weeks I also have this behavior…
64GB Apple TV 4K.
Had it yesterday right after the update to tvOS 17. I let Infuse redownload all metadata.
Today when I opened Infuse same error…
Error code: FCETA
I did get Tailscale working, at one point, I haven’t checked it yet, so I could reach OctoPrint on a Pi in my workshop so I can check the progress of 3D prints (and stop them if need be) from anywhere, not just from within my LAN (which extends over the house and barn, that are about 500’ apart, but each also has wifi - it would be SO cool if I could extend that wifi outdoors so it’s available in the woods between the house and barn!) Ultimately, I want to use Tailscale for OctoPrint, Home Assistant, and Plex (or whatever I use on my media server in the long run), and each is on a separate device.
On your other points, there are a few other factors that I think support your point:
- Bandwidth: Not everyone has high speed and high bandwidth. I was stuck with Viasat for 2 years and saw what bad internet was like. It was like having DSL and, if you used over 150GB of data, you had to pay a big chunk more or your speeds were reduced to about the same as dialup. I’m sure there are a number of other reasons people have poor internet.
Related to that point is that we could not stream much during that 2 years of poor internet. My solution was to start buying up TV shows on DVD. (Cost wise, there was a lot more viewing hour per dollar for a TV series than for movies.) I also ripped them to my RAID and used SAMBA to turn it into a simple media server. I’m sure a lot of people do this: Use physical media and buy up videos (or pirate it) I’m sure a lot of people without good internet do this, so forcing re-downloads of metadata are bad for people in that situation. Again, there should be some way to back up all that info locally.
-
If you had five devices that were independent and not often on the same network, I could see each one keeping their own DB on the system, but since they can all access that system for the actual files, again, it seems foolish to duplicate that effort and not store the metadata with the source files - and if that makes a better case for you and the server idea, that’s just fine.
-
Selective caching - you pointed out Plex will dig down 7 levels and catalog all the files. I keep thinking it would be smart for Infuse and similar programs to load data for what it needs as it needs it. Go down a directory level? Load the metadata for ONLY that directory. Once it’s loaded and displayed, THEN start caching for the subdirectories, but do NOT load metadata for files not in that directory tree…
Has anyone that didn’t much have this problem update to 17.0, and see no or a positive improvement? Any feedback other than @strwht on whether 17 is worse?