In my opinion, the most important thing about a programme for users is that it must be intuitive to use. It's like the stairs at the entrance to a shop, with every step the shop loses customers.
I was wondering what the best way to distribute is, assuming, for example, a typical music directory.
The files are already compressed, so further compression is pointless.
If I pack the files without compression into an archive container to keep them together, then I have to extract the file names and the description somehow and write them in an accompanying text or in an .mwcomment file.
This costs additional time and I can't afford to make any mistakes when scripting and I have to generally be able to create scripts. This way doesn't seem to be too good when I look at the results of others in MuWire so far.
If I leave the directory with the files it contains open, then I only have to pay a little attention to the file name convention. The file names and other details such as size and type are adopted by the programme.
It has now been discovered that MuWire does not accept directory names or empty files as information carriers.
In MuWire, a comment can still be entered via the directory name, which is then transferred to all files in the directory - except for the directory itself.
So when I repeatedly open the comment function of the directory, I see an empty field. If I now save the empty field, because there is no evident difference between "Save" and "Cancel", then the text that was previously painstakingly compiled is deleted from the other files.
The software designer must have had something in mind. It's just not clear to me what works and what doesn't. So what is the best solution for naming and describing files in conjunction with MuWire? Which way is better, creating archives or directories and files?
All beginnings are difficult. The files to be distributed
Re: All beginnings are difficult. The files to be distributed
Definitely directories, not archives. The "Options" -> "Preferences" -> "Search" tab -> "Search in shared folders" checkbox tells MuWire to search in the name of the folder when deciding whether to return a result.lgillis wrote: ↑Sat Aug 10, 2024 10:20 am
It has now been discovered that MuWire does not accept directory names or empty files as information carriers.
...
So what is the best solution for naming and describing files in conjunction with MuWire? Which way is better, creating archives or directories and files?
It is true that MuWire does not index empty files, that is by design. But if you have a Folder/File.mp3 then a search for "Folder" will return "File.mp3" as result, unless the checkbox mentioned above is unchecked. Note that the folder "Folder" itself has to be shared, not just all files in it. To achieve that you can drag-and-drop the folder on top of MuWire. If shared correctly, it will appear as solid colour in the Library tab. If you just share all the files inside a folder but not the folder itself, the folder name will appear grayed-out.
If the name of the folder appears in solid colour, you can right-click on it and configure some additional options such as who is alloiwed to see the files inside it. This feature is available in the latest source code, I don't think it's in the last released beta.
Please give it a try.
Re: All beginnings are difficult. The files to be distributed
This is switched on, by default. I had not made any changes.
> "Definitely directories, not archives."
Why? (s.a. Annie Lennox, 1992: Diva ;) [Addendum, because I'm not completely stupid and distribute the stuff I'm talking about here. https://inv.in.projectsegfau.lt/watch?v=HG7I4oniOyA Annie Lennox - Why (Official Music Video)]
Last edited by lgillis on Sat Aug 10, 2024 12:52 pm, edited 1 time in total.
Re: All beginnings are difficult. The files to be distributed
I agree, that was my first thought too. The question is, how often does it happen that someone specifically searches for individual titles? My observation is that the searches are based on the lowest common denominator. So instead of searching for an artist, they search for a file type.
How efficient is reading and storing individual files compared to archives with descriptive comments? For the sake of simplicity, let's assume that a directory contains 8 files. With 1000 albums we have 8000 files plus 1000 folders and possibly comments. On the other hand, there are 1000 archives, possibly with more or less extensive descriptions (mwcomments). How does this affect the consumption of bandwidth, RAM and power, what is more economical, also with regard to global warming? And before anyone laughs, they should ask Google about their energy consumption. Because in the long term, it's not about one request, but hundreds or even thousands every day that have to be answered by each individual client.
How efficient is reading and storing individual files compared to archives with descriptive comments? For the sake of simplicity, let's assume that a directory contains 8 files. With 1000 albums we have 8000 files plus 1000 folders and possibly comments. On the other hand, there are 1000 archives, possibly with more or less extensive descriptions (mwcomments). How does this affect the consumption of bandwidth, RAM and power, what is more economical, also with regard to global warming? And before anyone laughs, they should ask Google about their energy consumption. Because in the long term, it's not about one request, but hundreds or even thousands every day that have to be answered by each individual client.
Re: All beginnings are difficult. The files to be distributed
Regarding searches, even if most searches are for the lowest common denominator some are not, and I want MuWire to work well for those cases too. That is not only when searching for artist, but for specific song, etc.
Regarding resource consumption, obviously more shared files means more memory being used. However, a rough calculation I did a while ago showed that MuWire can index about 2 million files per 1 GB of RAM used. Regarding bandwidth, sharing individual files is many times more efficient because the downloader will transfer only the file they are interested in rather than a complete album/arvhive. I don't know how this translates to electricity usage, but given the encryption that happens over I2P and that traffic is usally routed through several nodes it seems to me that overall electric footprint is much lower when less bandwidth is used as as the case with individual files.
Regarding resource consumption, obviously more shared files means more memory being used. However, a rough calculation I did a while ago showed that MuWire can index about 2 million files per 1 GB of RAM used. Regarding bandwidth, sharing individual files is many times more efficient because the downloader will transfer only the file they are interested in rather than a complete album/arvhive. I don't know how this translates to electricity usage, but given the encryption that happens over I2P and that traffic is usally routed through several nodes it seems to me that overall electric footprint is much lower when less bandwidth is used as as the case with individual files.
Re: All beginnings are difficult. The files to be distributed
> "Regarding searches, even if most searches are for the lowest common denominator some are not, and I want MuWire to work well for those cases too. That is not only when searching for artist, but for specific song, etc."
This is perfectly legitimate. If the titles are written in the comments, they should also be found.
But there is something wrong with the search function. I can only find some of my own files via the file names (as described above) and also via the comments after a restart.
Have a Weekend!
This is perfectly legitimate. If the titles are written in the comments, they should also be found.
But there is something wrong with the search function. I can only find some of my own files via the file names (as described above) and also via the comments after a restart.
Have a Weekend!
Re: All beginnings are difficult. The files to be distributed
After a restart it takes some time for the library to load all shared files. By default this process is deliberately slowed down to 500 files/second to conserve CPU, so if you have many shared files this could take a while.
Take a look at "Options" -> "Configuration" -> "MuWire" tab -> "Sharing settings" -> "Throttle loading of shared files on startup" checkbox (the very bottom one). If you uncheck it and restart MuWire will load the shared files much faster but you will see a CPU usage spike.
If all files are loaded and you can find them using the "filter" text field in the "Library" tab but they're still not visible in search, then something may be wrong and I will need to take a look.
Have a good weekend you too!
Re: All beginnings are difficult. The files to be distributed
Taking into account the arguments presented, I propose the following convention for file names using the example of typical music directories and the files they contain.
In this way, no special characters or [square] brackets are required. Double minus signs are suitable for visually separating the technical features. (MuWire's search filters out the minus sign.) Keywords and metadata are separated by commas so that related words can be recognized as one keyword. In combination with a mono font, this looks very tidy and clear.
The directory name already contains most of the useful information. The information can be supplemented by linking the .mwcommt file to a text file with additional keywords.
Code: Select all
a) directory name and example:
Artist Date Album -- Genre, Genre, Genre -- Metadata, x Hz, y bit, Codec
James Holden 2068 The Rosinate is our home -- Space Blues, Psychill -- Hi-Res, 88200 Hz, 24 bit, Flac
b) file names (o=of like »Seven of Nine«):
Artist Date Album %{tracknumber}o%{tracktotal} Title.ext
James Holden 2068 The Rosinate Is Our Home 2o6 Naomi, my XO and great Love.flac
c) supplements:
Artist Date Album.jpg
Artist Date Album.description
d) MuWire comment-file (via link):
"Artist Date Album.description.mwcomment" -> "Artist Date Album.description"
The directory name already contains most of the useful information. The information can be supplemented by linking the .mwcommt file to a text file with additional keywords.