/jp/ - Otaku Culture

>>35965664
Sorry OP but I'm too retarded to understand what they're doing there

>>35965664
>Have an application that performs a mapping between SQL tables/rows/statements and a filesystem: a path becomes a query and query results become files.
>You don't need experience in developing kernel drivers to write a program that implements what you need. Userspace will cost you in performance, but it also means things are easier to pick apart and a mistake won't crash your system.
Without poring over the source that about sums it up, with the actual implementation being:
>when started the program examines the databases directory. For each database [with a fixed name] it looks at its table and column names and presents them as directories. Right now it assumes certain db structure (starlike acyclic schema), in general case it could be supplied some hints by the db author. When, by entering a directory, you choose a table.column pair the program searches the db for all distinct values of this combination and lists them as the next layer of directories. You can choose a value then, this creates a constraint on results. Next you can choose another table.column, see what options you have there and so on. Once there is enough information to uniquely identify an item the full implementation is supposed to look up its corresponding file(s) and provide them as a passthrough fs (mine just returns a dummy).

I haven't touched C++ or FUSE, but going by the current source code a lot of the kernel FS interfaces are still undefined, along with any special logic for certain command line utilities. So it looks like a PoC at this point, but who knows what will come of it.
FUSE was probably a good choice for this for easing adoption, since it's all userspace and doesn't involve messing with your current FS.

>>35965664
I'll read the rest later, but I had a similar idea. FLAC for the download, smaller filesizes like OPUS for web play.
Assuming there would be a player of course. It seems costly to stream FLAC directly with the fuckhuge filesize.

http://151.80.40.155/

something like this?

>>35965664
This will be complicated for anybody not into software. The author should go two steps further and create a full-blown program that runs in the background, automatically indexes everything within directory x and any subdirectories and provides a web UI with a simpler search interface

Anything more than that is too much for your average doujin music enthusiast

>>35968076
Yeah, basically that

>>35971205
>The author should go two steps further and create a full-blown program that runs in the background, automatically indexes everything within directory x and any subdirectories and provides a web UI with a simpler search interface
That already exists and is not the exact problem they are trying to solve.
And also FUSE-based OSes can be a set-it-and-and-forget-it situation, especially with Windows now supporting FUSE.

>>35971205
>>35972312
Oh and I should clarify: the problem/solution you identify, while valid, is much more constrained by its implementation, and is the pain point the author is looking at:
>The author should go two steps further and create a full-blown program that runs in the background, automatically indexes everything within directory x and any subdirectories
This is what the author intends to create, but not as a particular program. Rather, it is an entire FUSE userland FS that abstracts database queries into filesystem calls and directory/file/metadata structure, rather than making a program which talks to a specific DB in a specific language.
>and provides a web UI with a simpler search interface
You could do that with this approach as well. Actually, it would be even easier to implement unless the developer has no context for FS calls and only SQL, which I think is only common upon dedicated DB devs.
This FUSE layer has two really cool advantages if/when it is actually implemented:
1. You can interact with files in a database without implementing a DB yourself. You could even interact with it using shell scripting.
2. A lot of programs, like core file utils (mv, cp, echo, cat), media players (mpv), file transfer (rsync, scp), encoders (ffmpeg), etc. can now interact and process files with DB-level precision with their current FS-level tools, or can be wrapped around with shell.

IMHO you're selling the idea pretty short. It wouldn't be much used by non-coders directly, but it greatly simplifies DB interaction for tools that have no concept of a DB.

>>35967782
That's not similar at all to what the OP is proposing, but there is actually already a self-hosted solution to that I would recommend, Subsonic:
http://www.subsonic.org/pages/index.jsp
No longer FOSS, but there are forks which are. It's a java-based media server for music/videos. Its video support is pretty meh compared to something like plex, but for music it's the best I've come across, and let's you manually specify the transcoding of music on a per-device basis, like pic related. I have it set up to do FLAC on everything but mobile network on my phone (via Ultrasonic app), and then OPUS on mobile network. Works like a charm.

The only caveat with the TLMC is that Subsonic is built to recognize songs on a per-file basis, so the one file per albums TTAs in the TLMC have to be preemptively split into single tracks by another program before scanning them into Subsonic (unless you don't mind missing track-seeking). IMHO this is more of the TLMC doggedly sticking to a niche ripping standard not even the Japanese use much anymore than a big fault of Subsonic.

>>35976449
I realized that when I read over it again.
At the time, I speed read over it so I didn't notice it would all be client side.

>The only caveat with the TLMC is that Subsonic is built to recognize songs on a per-file basis, so the one file per albums TTAs in the TLMC have to be preemptively split into single tracks by another program before scanning them into Subsonic (unless you don't mind missing track-seeking).
Well it's going to be fun getting around that.

>>35976359
>can now interact and process files with DB-level precision with their current FS-level tools, or can be wrapped around with shell.
This is what's so important, your simple UI for doujin fans isn't coming with this, but what this is is something that is trivially extensible into whatever it is you want / need.

Looking forward to this, cool stuff.

>>35980033
>Well it's going to be fun getting around that.
Solved problem, I've done it before. I just used some combo of cuesplit and ffmpeg, but there's this:
https://bbs.archlinux.org/viewtopic.php?id=75774
Just do it piecemeal if space is an issue. Only issue if you need both the TTAs for seeding and FLACs for *sonic. Personally just threw the latter on my NAS.
But none of this is hard.

Thank you all anons. I was thinking the thread will probably get archived pretty quickly but you guys surprised me.

>>35985188
boo

>>35985188
/jp/ is full of surprises.