andresch
commented
11 months ago Hi bobmvg,
Thanks for using trackfs.
The wrong file size is a limitation of the fundamental design of trackfs. The virtual filesystem you see doesn't exits anywhere on disk, but is created on the fly by reading directories and metadata from the flac+cue files in the source filesystem. Only when an application opens one of the virtual track files in this virtual filesystem, trackfs extracts an individual track from the source flac+cue file (by recoding a part of the source file) in a temporary file. And only after that I would know how big the track file actually is.
The same applies to entries of the virtual directories. They file information for all entries of a directory are generated on the fly from the source directory by adding additional entries for each track I find in track+cue files in the source directory. For each track entry I have to provide some size information. The current implementation always provides a value that corresponds to the size of a non-compressed audio file. Unfortunately I did not find a way to reliably predict the flac compressed size of the track.
In my various experiments I never had issues with too big file size values, only with too little ones -- hence my decision to go for a upper bound. While this always worked for me and my audioplayer, it obviously it doesn't work for you.
If I would have to re-encode all individual tracks before I could respond to directory list requests, then this would take ages and make trackfs filesystem unusable.
Unfortunately I have no reasonable idea how to overcome this problem without changing the fundamental, low-tech architecture of trackfs: Rather that doing everything on the fly, trackfs would during initialization have to once recode all tracks and then store the size values in some database. This would not only significantly change the complexity of my small implementation. For large music collection such an initialization would also run for hours, while now trackfs is ready to run within milliseconds.
The only solution that would come to my mind for your setup is to do some automatic copy/backup of the virtual file system to some physical file system. As you've seen, the copy operation of your operating system can deal with the wrong file size easily. Then the files on that file system would have the actual file size; but of course you would then also need twice as much disk space. Not nice; but maybe still acceptable.
I do not know exactly why mediainfo gives different bit rates on the two files. I would guess the bitrate is not stored directly in the file's metadata, but just calculated by dividing the file size (from the file-system) with the track duration. At least that would explain the difference.
I am sorry for not being able to provide a solution for your problem with trackfs directly. Would be curious to learn if you found a way that works for you. Might be interesting for others that run into similar issues.
Andreas
BTW: When I initially wrote trackfs I was hoping to find some means to directly read the already encoded track from the source file. My hope was that this would allow me to improve the track read performance significantly and could then I could most likely also directly calculate the size of the track from the source file. But unfortunately I never got a response for the creators of the flac encoding on my question if this would be possible. Hence I currently have no alternative to extract and recode each individual track.
bobmvg
Hello. Thank you for the excellent program! I use it to distribute a small music collection (FLAC Image+CUE) via DLNA (minidlna) for playback on LG TV. Mostly everything works fine, but after dividing some albums into tracks, trackfs reports the wrong file sizes for individual tracks.
Here is the track information from the Fuse file system and the mediainfo output for one of the tracks:
This file gives an error when played (here is part of the minidlna log):
If I copy the same files from the Fuse file system to a real hard drive, then the copied files are smaller in size, mediainfo shows a smaller size and a different bitrate:
These files play normally.
Here is a link to the original files to check (FLAC Image+CUE): https://drive.google.com/file/d/11Dp453WCW6Lk3jD_7Cwiku6pJ2_2Tocp/view?usp=sharing