search/browse the music database without filesystem access

[6arms1leg]

my music is on an external drive. when this drive isnt mounted, cherrymusic cant search its music database. isnt it one of the advantages of this database, that it actually doesnt search on the filesystem but in the batabase? or does cherrymusic check after the search if the path in the database really exists? would be really nice to search and browse without accessing the filesystem. i have some need for this, as my external drive has a powersaving mode and any access wakes it, which takes some time and is totally unnecesary until i actually want to play a track. can we implement that? thats one of the features i like about mpd, i really want this...

[tilboerner]

or does cherrymusic check after the search if the path in the database really exists?

yes. cherrymusic not only has no appropriate response to handle inexistent files in the search results -- it's being downright nasty about them. see #96.

it doesn't have to be this way. about the actual feature request, I don't care either way. ^^

[devsnd]

i understand your problem very well: It does the same thing on the testserver, and since the testserver is 1000km away, I certainly can't hear the harddisk spinning up :ear: However, I think it is more important to have proper search results, than taking care of harddrive spinup times, since in the end, the actual client will not know on what kind of setup cherrymusic is running on.

The safe checks can be easily turned off, and we could provide a config switch for that... but I'm not comfortable with it. Maybe, now that we have the new configuration interface, we could make it a hidden config switch, so that it will not be written into the --newconfig file, but can be activated, if you know the key.

Is this agreeable?

[tilboerner]

In cherrymodel.search, we could get the isdir information directly from the database instead of querying the filesystem; that would remove the need for the existence check as well, and the "Search" tab should be free of filesystem access.

[tilboerner]

(Ah, why do I keep hitting ctrl+enter when I mean enter? Damn you, facebook, I'm blaming you!)

That would leave "Browse", which operates directly on the filesystem.

[tilboerner]

... and I forgot to add: I still think missing files will be rare occurrences, so it should be ok to list them... as long as there's a proper way to notify the user when he tries to play them, or better, add them to the queue or another playlist.

[6arms1leg]

Is this agreeable?

sure, that would be great! i need that feature.

but why do we have these safe checks in the first place? i dont see why this conflics with the need for proper search results. the search query lists results that are in the database, thats simple logic. if some tracks in the database are missing on the filesystem, then the database is not up to date. why not just remove the check, or delay it until a file is played? i know, a remote client dont know about the datatbase and stuff, but if a track is missing, there could be a simple error messsage, explaining that the database is not in sync.

and why dont you want this in the config file? i know, this might confuse some users, but that cant be a reason for hiding nice detailed options from power users that love to tweak such things. maybe a small warning would do the job, like "only edit this, of you know what you are doing".

anyway, your decision...

[6arms1leg]

I still think missing files will be rare occurrences, so it should be ok to list them... as long as they'res a proper way to notify the user when he tries to play them

exactly!

That would leave "Browse", which operates directly on the filesystem.

which is a good feature. i like the option to browse the actual filesystem instead of the database. i know, i start getting on your nerves with this "lets make than an option" thing, but why not making a button in the webinterface on the browser tab to choose between database and filesystem? that would be awesome.

[devsnd]

Also, ResultOrder relies on some file operations. This might be overcome be rewriting it so that it uses MusicEntrys instead of file names. Would be cleaner any way. I think this issue is a good way to clean up some things we didn't care about to much.

But my focus still relies on the user on the client side. I don't want them to have a popup box, saying "You cannot listen to the song you have just found. it's someone elses fault, but you also will not know when it's resolved. Furthermore, you will encounter this message randomly in the future."

So I think we should do this, mainly to have a clean interface, but in the end, it will stay a hidden switch.

[devsnd]

making a button in the webinterface on the browser tab to choose between database and filesystem? that would be awesome.

Well, ... I think I know where you're getting now. The search provides only shortcuts to folders in the browser, but you'd like it to be completely database based. This is something completely different of what I thought you were talking about ;)

[6arms1leg]

[...] but in the end, it will stay a hidden switch.

i see your point and maybe you are right about that error message, but i still dont get the "hidden switch" thing. why hidden? i think hiding stuff from the user is the wrong way, i takes away control and i dont like that idea. it yould be an option that by default is turned off. like ssl encryption is... someone who know what ssl encryption is probably can figure the difference between a database and a filesystem.

[6arms1leg]

Well, ... I think I know where you're getting now. The search provides only shortcuts to folders in the browser, but you'd like it to be completely database based. This is something completely different of what I thought you were talking about ;)

for me this issue was about the possibility to completely search/browse my music, edit playlists etc., without accessing the filesystem (to avoid waking the external hard drive). the brower reads the filesystem, which on some occaisons is a good thing, so that you dont entirely depend on the database (e.g. you havent run a database update recently but added some tracks). on the other hand it might be necessary to use the browser to locate a track and i also want to be able to do that without spinning up any hard drives.

[tilboerner]

@6arms1leg, then I misunderstood, I thought you wanted browse to work through the database, too. I'm content with how it is, and I'd be fine with changing it. But I don't like the thought of having two systems in place with an option to choose. I think that option would be a boon to very few people, and a burden to the rest.

About hidden options. Hidden options are useful for developers to tweak parts of the system, but usually of little interest to the user. What's useful to us has a right to exist. :) These options should be documented somewhere that is not the front page, but nothing prevents anyone to read about them and use them as well... They're just nothing to hit the normal user over the head with.

(e.g. you havent run a database update recently but added some tracks).

Your fault, then. I don't think cherrymusic should go out of its way to provide for a situation like that.

rewriting it so that it uses MusicEntrys instead of file names. Would be cleaner any way.

I like that. For a while now, using MusicEntrys in more places has been a secret fantasy of mine. ^^

[6arms1leg]

Your fault, then. I don't think cherrymusic should go out of its way to provide for a situation like that.

hmm, maybe you are right. but then your argument also works the other way around: cherrymusic has no need for file existance checks in the search, as it expects the database to be in sync with the music library, anyway.

im absolutely fine with this hidden switch option. but please also enable this for the file browser, thats what this issue initially was all about: using all features of cherrymusic (browse/search the database, editing playlists, etc) without accessing the filesystem until a track gets played. (i hope everyone understands what i mean now^^)

thanks for your patience.

[tilboerner]

argument also works the other way around: cherrymusic has no need for file existance checks in the search

true. but it keeps the user from seeing cherrymusic's buttcrack, so i consider it an expense well paid. ^^ also, removing the existence check still leaves the isdir check in place, so to be effective, we'd have to change the sqlitecache interface a bit to remove both of them.

please let's not write a second browser that works on the database and hide it behind a secret switch. that sounds really useless! like putting an entire second engine into a car that's specially engineered to use Flutschi brand oil for lubrification, and only mention it in a footnote of the manual.

let's decide which way is better and then either change the browser to forget about the filesystem, or leave it as is. (sorry @6arms1leg!)

[6arms1leg]

:-1: i vote for the database version then. spin ups for my external drive take about 10 sec, and since nowadays everything has to be super green, extra eco, -100 emmissions it goes into powersaving mode after about 7 min. many new drives do that. so if you take a short break while creating a new playlist, the drive is already in powersaving mode again and has to spin up again. that shortens its lifespan and delays search results/browsing by 10 sec. in my opinion the benefit from not accessing the disk until its really necessary is worth more than rare missing file occurrences, which are the fault of the user anyway when his database is not in sync. for a correctly working program that operates on a database, the database must be in sync. thats logic, thats simple. i think we should use that benefit from the database. technically its stupid to have a database to return search results in a second when the listing of the search results is delayed another 10 sec to check them for existance. same for the file browser. and all that because we expect the user to be completely dumb.

i bet you have the same problem with your drive.^^ test it! maybe then you are with me on this. i know im not the one who decides this, but i vote for a (hidden) switch to make cherrymusic completely based on its database until playing a track. :+1:

[6arms1leg]

let's decide which way is better and then either change the browser to forget about the filesystem, or leave it as is.

thats bad for the sake of consistency. changing the browser to work on the database while leaving the deafault search (with hidden switch off) with existance checks would return in different file listings for both: when not synced, the browser would list removed tracks while the search function wouldnt. wait, thats what cherrymusic does at the moment, only the other way around, right? if tracks are added without a database update the browser lists the new files while they are not included in the search.

didnt think about it that much until now...

[6arms1leg]

disregard my posts above, i made up my mind. i stopped drinking and go to church again. so now that i smoked some crack this morning i came to the conclusion that everything is fine if there was a hidden switch to turn off file existance checks for the search. thats all, lets leave it at that. the browser being filesystem based is fine. its also a kind of fallback solution, as the broswer simply lists directories, nothing much can go wrong. when i dont want to spin up the drive while creating a playlist i can use the search. hidden switch and this issue can be closed. sorry...

[6arms1leg]

@devsnd: can you please provide some info about this topic? what is the reason for closing? what have you decided to do? what has been implemented? i noticed this commit:

https://github.com/devsnd/cherrymusic/commit/b0711f42e0a1b5ac38696729eba7e92399f14e0c

the commit looks like file existance checks were removed alltogether. i thought you wanted a hidden switch for that... dont get me wrong, im just curious what the final decision now is on this topic. can you please explain the behaviour of the search panel and browser now? what needs filesystem access and what doesnt...

i also noticed something strange and i dont know yet if that should go into a new issue or not: i added a new album of an already existing (=existing in the db) artist and this album is listed in the search results without a database update. how is that possible? should that go into a new issue or is that somehow part of the mentioned commit obove?

[tilboerner]

@6arms1leg , you probably mean 340c30d2128f940337a548db242cb4a931b659f9, right?

As mentioned above, there were two reasons for the existence check:

• a bug that materialized when a search returned inexistent files: #96; and
• showing inexistent stuff to the user isn't the best idea in general.

There was also another file system access in the search handler; the commit mentioned above got rid of it and of the existence checks as well. What we get is improved search speed and the added benefit of not spinning up any disk just from a search.

Unfortunately the two reasons above stay in effect. This means the bug is now un-fixed.

this album is listed in the search results without a database update

is it listed as a direct result or after clicking open a directory in the results list? because clicking open directories there results in an api/listdir call, which operates on the filesystem, not the db. (so, yeah, clicking folders in search would cause your hard disk to wake up).

[6arms1leg]

@6arms1leg , you probably mean 340c30d, right?

right, i meant that one. somehow i cp the wrong one. sorry for the confusion.

[...] What we get is improved search speed and the added benefit of not spinning up any disk just from a search.

so you decided against a hidden switch?

is it listed as a direct result or after clicking open a directory in the results list?

yes.

because clicking open directories there results in an api/listdir call, which operates on the filesystem, not the db. (so, yeah, clicking folders in search would cause your hard disk to wake up).

ok, thats what i figured. im not the one who implement these things, but in my opinion the way it is now is a bad concept. (no offense and sorry again for starting this discussion all over again.) searching the db without filesystem access but list the search results based on the filesystem (listdir call) when clicking on a directory in this list may result in faster search queries but doesnt solve this issue.

my hope for this feature request was (after our long discussion): being able to search or browse the complete db without filesystem access (=>spinning up the harddrive).

i thought we agreed on: search operates entirely on the database (maybe enabled by a hidden switch), and file browser operates on the filesystem.

common, i really need that feature. i want to be able to search/browse the database and create/add playlists without filesystem access. so that filesystem access is only needed when actually playing music. its almost christmas.^^ :christmas_tree:

the behaviour right now is like listing inexistant files only the other way around: listing more than whats acually in the db. its not as bad, but its not logic and confusing. this is my most wanted feature, please dont reject it and think about it again.

[tilboerner]

Alright, here's what I'm thinking. I'm a bit tired, so the text is a bit long.

I think we should be free to operate on any combination of database / filesystem access that strikes us as the best compromise to achieve a simple, clean, efficient and responsive interface. That's the primary goal.

Needing to power up some rotating disks is highly undesirable, mainly because of the delay it causes. There's a good chance the basedir is on a separate physical disk, so one solution might be to go without accessing it unless absolutely necessary. But what about accessing it more? Why shouldn't another solution be to try to prevent this drive from spinning down while cherrymusic is being actively used? Just saying, let's keep our eyes open.

I'm not ready to buy into the lifespan argument. Firstly, storage is supposed to be cheap, and unlike 1930s era flash bulbs, it's made to survive being used. And then, while we shouldn't go out of our way to actively decrease the lifetime of anyone's hardware, we're also not developing cherrymusic to make it last longer. Cherrymusic is about the music you keep around, so while you're using cherrymusic, expect your music hard drive to see some action.

As for sync issues between basedir and database: in normal operation, this would happen because someone made some changes in basedir without cherrymusic getting updated. So it's up to the admin to keep cherrymusic updated, and I think that's a very reasonable thing to expect.

Our task as developers is supporting this by making updates as painless as possible. This gets priority over smoothing out these out-of-sync states: a functional breakdown is bad and should be prevented; still, some extraordinary things happening may not be optimal, but ultimately acceptable. That being said, these extraordinary things should be as un-weird as possible and tend towards the consistent and explainable.

Now, something about the search/browse aspect, basically because I want to squash it as much as I can.

The thing is, there is no clear distinction between "searching" and "browsing". And that's okay, because there is no reason why there should be two different concepts, or "modes", of finding stuff in your collection. I know there's another Issue where I'm advocating a clear split of "search" and "browse" into equivalent panels with their own state; but that's mainly to improve the consistency of an interface where such a split is inherent.

What search really accomplishes is to radically narrow down the data to browse through. You're still browsing, but with a filter in effect that quietly removes uninteresting options, while also transcending hierarchies -- hierarchies which are mainly needed to make an over-abundance of choice manageable.

So, ideally, I'd like an interface that combines browsing with filters, one of them a "freestyle" text filter, a.k.a. search. If there's no active filter, you simply get to browse the whole library.

Things like "filesystem" and "database" are totally transparent to the user, transparent in the sense that it's not clear where the data come from, because such knowledge is not necessary. Incidentally, the "library" is not just whatever's in your basedir; it's absolutely based on the file system, yes, but it might also be augmented with data that comes from inside cherrymusic, like playlists, playcounts, recommendations, etc. Playlists, for example, are also an item in the library: just another way to organize tracks, totally equivalent to something like a directory.

This is just an idea I have in mind. We don't need to ever go there, but I think it's a very interesting concept, that may be fun and challenging to explore, and rewarding UI-wise.

[6arms1leg]

above the fold: i totally agree.

after the fold: nice ideas, i also would be interested in that. but they exceed this issue by far. why dont we make a new issue for that, so it can be evaluated seprately with all the other new-ui issues?

[tilboerner]

why dont we make a new issue for that, so it can be evaluated seprately with all the other new-ui issues?

maybe we should, but I'm not sure how many issues are hiding in there. ^^ I also think this is something we shouldn't tackle before getting the new UI into a steady state to base future development on. for now, I just wanted to put a lid on the search vs. browse part of this discussion, by telling you why I consider it beside the point.

meanwhile, in light of the stuff "above the fold", what do we do about this issue here?

[6arms1leg]

[...] Needing to power up some rotating disks is highly undesirable, mainly because of the delay it causes. There's a good chance the basedir is on a separate physical disk, so one solution might be to go without accessing it unless absolutely necessary.

until here, i totally agree.

But what about accessing it more? Why shouldn't another solution be to try to prevent this drive from spinning down while cherrymusic is being actively used? Just saying, let's keep our eyes open.

i absolutely disagree. on a server thats running all the time this would mean to circumvent all power saving features. a normal 3,5" hdd needs between 7 and 15 W average when idle. a server is sunning all the time, so this is like leaving your light (energy saving bulb) in the bathroom always on. why should we do that, when there is no need for it?

I'm not ready to buy into the lifespan argument. [...]

you are right.

As for sync issues between basedir and database: in normal operation, this would happen because someone made some changes in basedir without cherrymusic getting updated. So it's up to the admin to keep cherrymusic updated, and I think that's a very reasonable thing to expect.

exactly.

lets hear what @devsnd has to say.

[devsnd]

We've got a dilemma here:

• Reliying purely on the database enables us not to use the harddrive, as long as no music is played back. This is great and desirable. But this also means, that the database has to be up to date all the time, because we otherwise can't tell if a file exists or not.
• Updating the database requires the harddrive to crawl through all files. To make sure it is always up to date, we need to update all the time. Therefore, we can only achieve initial the goal, if we miss it.

Personally, I think the update switch is the worst part of cherrymusic. Who in the world wants to flip it? I don't. I simply don't want to think about my database being up-to-date, when I originally just wanted to listen to music.

The only solution is to make cherrymusic aware of the filesystem, so that the database automatically updated, so we don't need to access any files (except when actually streaming them).

There is two solutions to that:

1. We could have a look on inotify. There seems to be a pyton binding for it, we might use: http://pyinotify.sourceforge.net/

   The main drawback is the amount of files, that can be watched simultaniously:

   From the inotifywait man page:

   The default maximum is 8192; it can be increased by writing to /proc/sys/fs/inotify/max_user_watches.

   This means that by default, we effectively could only watch the root folder...

   Also, I don't know what this means performance wise for the server.

2. Try to do it ourselves, by comparing mtime of all folders. From a bsd mailing list:

   The mtime of a directory is updated when the directory "file" changes. Directory "file"s contain filenames and their associated inode numbers. Modify any of that information (e.g., create a new file, remove or rename an existing file), and the mtime will be changed. Changing the ctime or mtime of a file within a directory does not modify that of the directory itself.

   This means, that we can assume changes within a directory, if the mtime changes. Unfortunately, this also only works for direct parent-directories, so we still have to traverse through the whole tree, but we could leave out scanning all directories not containing another directory. This might lead to a huge speed up, because we can stop looking at many individual files and lead to a more practical update-mechanism, which is more lightweight. It could in turn trigger the original partial update for any changed folder.

Anyhow: I think we're scratching on the limits of the feasable. We're talking about a very low-powered computer (RPi) having to manage a huge collection of files on a external harddrive over a slow interface (USB2)...

[tilboerner]

try to prevent this drive from spinning down while cherrymusic is being actively used

i absolutely disagree. on a server thats running all the time...

i should clarify my original statement: i wasn't thinking of the cherrymusic process itself keeping the drive busy. but if a user is logged in and interacting with the server to play music or manage playlists or whatever, maybe there's a way for these interactions to involve some light basedir read activity that actually makes sense to do, without slowing down responsiveness? not that we should just invent something for the sake of this issue; but the issue might go away by itself because of, you know, us being ingenious and all that.

I think the update switch is the worst part of cherrymusic.

Yeah, it's not pretty. I agree that the ultimate way to make updates painless is to make them automatic. Here's my personal list of requirements for such a feature:

• portable

  i'd hate to make features dependent on the OS you're running. relying on a single OS-specific functionality isn't gonna cut it, if there's no way to get equivalent results on another system. even then, i'd rather avoid having different implementations for different OSes. that's why inotify and mtime don't exactly make me giddy with joy.

• low overhead

  must be able to handle tens, even hundreds of kilofiles spread over quite a number of kilo-directories, in a tree structure of quite variable depth, without hogging the resources of a slighty retro hardware setup. i don't trust common off-the-shelf solutions in that regard: fam, gamin or pynotify seem to be meant for other tasks, but i have to admit i haven't tried either, at all.

  at the same time, this data tree is very static; after intitial setup, we can expect changes to be rare and highly localized. maybe there are some tools for that kind of situation, otherwise we're looking at DIY. build a throttled background file-crawler that is only active under certain conditions?

• optional

  there will be economic setups which are totally overtaxed by whatever automatic update algorithm we implement; there might also be other situations where an autoupdate is not desirable. that's why updates must remain under ultimate admin control, and why there must be an easy way to update manually. hello there, update switch. :kiss:

okay, now we're talking about auto-updates. this issue is all over the place; very interestingly so, but i don't like this lack of focus. can we wrap this up and get back on track somehow?

if I understand correctly, this issue is about avoiding frequent waiting periods during normal use of the cherrymusic web service, which are directly related to the need for a disk to wake up. there's obviously a complex background to this issue; but is there anything we can do right away to resolve it?

because if it turns out we need to reconfigure the warp core to really do something about it, it's better to close this issue, and turn it into one of the things that should inform a well thought-out hyperdrive overhaul, which I feel is due sometime before going v1.0.0, and hopefully a little sooner.

[tilboerner]

well, i still feel productive, writing so many words and all. :sob:

[tilboerner]

wait, this affects the browser as well, right? everybody okay with this? if so, permission to rename the config key, please.

[tilboerner]

merde, picked the wrong issue number in the commit message: 392410e179c16c4f78e3293c3c826f9616965079

listdir didn't work for directories with a . in their name.

I also get an error on my local machine when I switch to the browser: this seems to trigger a listdir(''), which fails, because there is no empty string in the database.

there's a quick fix, but it involves replacing the whole listdir implementation with some stuff that was originally written for the updater:

basedir = cherry.config.media.basedir.str
targetpath = os.path.join(basedir, path)
targetdir = self.db_find_file_by_path(targetpath)
if targetdir is None:
                log.e('media cache cannot listdir %r: path not in database', path)
                return []
return list(map(lambda f: f.basename, self.fetch_child_files(targetdir)))

edit: didn't wanna do this without asking first.

[devsnd]

Well do it, I don't care. I want this issue gone. You may also rename the config key then.

[6arms1leg]

hmmm, i know you both probably hate this issue by now, but it seems this still isnt working. well, im not quite sure what you implemented now, maybe one of you can give me a few infos about it.

until then:

• the browser still needs filesystem access (or is it meant to stay that way?)
• searching works for the initial search query only. as soon as i click on a directory in the search result list, the filesystem is accessed. adding tracks to queue/playlist also results in a filesystem access.

pure_database_lookup in the config file is set to True of course.

[tilboerner]

No, you're right to complain, this is supposed to be solved, after all, and it isn't. There are still two os.path.isDir() calls in httphandler that nobody had on the radar, which I think are responsible. (one, two).

[tilboerner]

oops, forgot to answer about half of what you said, sorry.

the browser still needs filesystem access (or is it meant to stay that way?)

the "search" browser and the "browse" browser are really the same thing: a listdir call to the API, except that in search the panel is initially populated with search hits. any changes to how the browser works are reflected in both "modes". the browser is supposed not to touch the basedir when pure_database_lookup is True, but the two lines mentioned above still do. i'm gonna fix that in a sec.edit: see next comment.

adding tracks to queue/playlist also results in a filesystem access.

that would be audioread and stagger trying to answer the getsonginfo API call. as a workaround, it should be possible to get rid of both modules (uninstall stagger, rename the audioread subdirectory in cherrymusic); this will disable everything based on song metainfo (length, tags).

to fix this in the sense of this issue would be more complicated. more on that later, I guess.

[tilboerner]

found one more disk access.

I'm starting to think that these things are too distributed to really make promises about any pure_database_lookup and expect to keep them in the future. look how quickly we can get it to work! just tweak one spot and it's done, right? :-/

like this, how can we guarantee that we won't ever introduce disk I/O into pure_database_lookup = True? always checking this config key is no solution, either. the textbook solution for this is to use a "strategy pattern": confine all disk access to one strategy class, make an alternate strategy without disk access, and decide exactly once which gets used.

we're talking quite a bit of refactoring work here, because it touches on a lot - so much, in fact, that it makes me question the feasibility and the value we'd derive from it. because, you see, this issue isn't just about browser.pure_database_lookup; it's about cherrymusic.dont_touch_my_music_drive_until_i_play_a_song. how much is a config key like browser.pure_database_lookup worth if any other api call, existent or still to be invented, may wake up the disk? does it even make sense?

the more i get involved in this issue, the more convinced i am that it is too big for just a config key. if we're serious about this kind of thing, if we want to really stick to it, it needs to be a core design principle: cherry music will not access your basedir except for db updates and when explicitly requested to serve an audio file.

if we're serious about this, there's not much sense in making this optional, unless we're here to drive ourselves crazy.

if we're serious about this, we better make it the one and only, the default behavior: everything goes in a database, which can be updated on two occasions only: on --update and /serve. do we want to do this? apart from the sleeping disk, what pros and cons are there?

@6arms1leg, when your disk falls asleep on you while you're doing stuff in cherrymusic, what exactly are you doing? maybe we can throw a quick read in there, to keep your disk awake...

[6arms1leg]

thanks for your explanation and for trying to fix this!

im sorry for the trouble this issue causes, @devsnd is annoyed by it already. if implementing this really causes too much effort and its not gonna happen, stop wasting time on it and close this issue. but as i said, for me its the most wanted feature. i love this about mpd. so otherwise:

if we're serious about this kind of thing, if we want to really stick to it, it needs to be a core design principle: cherry music will not access your basedir except for db updates and when explicitly requested to serve an audio file.

that would be my (personal) favourite.

if we're serious about this, we better make it the one and only, the default behavior: everything goes in a database, which can be updated on two occasions only: on --update and /serve. do we want to do this? apart from the sleeping disk, what pros and cons are there?

they were all mentioned at some point in this endless discussion. since im all for this issue, i will only give you pros^^. less disk access means:

• much faster (fs access is slower in general + on a powersaving hdd spinup takes ~8 sec.)
• consistency (its only shown whats actually in the db)
• less power consumtion
• more quiet (no hdd noise)

@6arms1leg, when your disk falls asleep on you while you're doing stuff in cherrymusic, what exactly are you doing? maybe we can throw a quick read in there, to keep your disk awake...

thanks for consideration, but no, thats not the point. that would only be a dirty workaround. i dont want you to implement some dirty code just to keep my disk from spinning up/down. as you said yourself, its all about the core principle: if it cannot be implemented cleanly with a config key, lets decide what principle we want to stick with (all or nothing).

[tilboerner]

maybe we can throw a quick read in there, to keep your disk awake...

that would only be a dirty workaround

hey, we don't know that yet! it also looks like that's your last chance to get the real issue fixed, at least for quite a while. this is big to implement, and unless we find some equally big benefit in it that has nothing to do with the HDD, it won't get done, sorry.

so, yeah, what are you spending time with in cherrymusic? this is also interesting from a user experience perspective. you can whisper it in my ear if you wanna. ;)

[6arms1leg]

hey, we don't know that yet! it also looks like that's your last chance to get the real issue fixed, at least for quite a while.

all or nothing. if this was done, it should be done right. and im convinced that this issue is a good feature. i know its a complicated issue, but i can wait, as long as i know it gets implemented some day. otherwise close it.

so, yeah, what are you spending time with in cherrymusic? this is also interesting from a user experience perspective.

basically, i do three things: listening to music ( :astonished: ), editing playlists, searching for stuff in my library. all that not locally, but over the network.

[tilboerner]

listening to music ( :astonished: ), editing playlists, searching for stuff in my library.

Ah, so the disk falls asleep not while you're working with cherrymusic, but when you do something else for a while. Somehow I thought you had found a case where normal use of cherrymusic would make you wait for the disk every couple of minutes. (For example, spending lots of time reordering tracks in playlists. I'd wanna know if people do that.) Good thing we clarified that.

I still need to make up my mind what to do about this issue in the long run. I'm inclined to close it for good, but I'm hesitating because you feel so strongly about it. Can you try to give me an estimate how annoying it is? Not how much you're annoyed that it happens at all, but something like, how often do you feel you have to wait for the disk.. per hour of using cherrymusic? Or per day? Or per "cherrymusic session", which is the time from first opening the web interface until you're done with it, possibly taking breaks or doing other stuff in between. Whatever pseudo-measure you think works best, go for it.

I'd like to get a feeling for how much "wait" there is. I guess I should also spend more time making playlists on the testserver...

[6arms1leg]

Ah, so the disk falls asleep not while you're working with cherrymusic, but when you do something else for a while.

not only then, it also happens while i work with cherrymusic. and think about the use as a server: if you have several users that connect to cherrymusic once per hour (maybe just creating playlists), they are also affected by this issue. so the total number of occasions this happens per day also depends on the number of connected users.

Somehow I thought you had found a case where normal use of cherrymusic would make you wait for the disk every couple of minutes. (For example, spending lots of time reordering tracks in playlists. I'd wanna know if people do that.) Good thing we clarified that.

exactly. also when searching for tracks in the music library for a while (without playing music). the rest of the time it happens when taking a break for some minutes (e.g. grab a snack or phone call, anything that takes more than ~5 min). im still wondering why you are not bothered by this. the testserver has the same setup after all.

I still need to make up my mind what to do about this issue in the long run. I'm inclined to close it for good, but I'm hesitating because you feel so strongly about it. Can you try to give me an estimate how annoying it is? Not how much you're annoyed that it happens at all, but something like, how often do you feel you have to wait for the disk.. per hour of using cherrymusic? Or per day? Or per "cherrymusic session", which is the time from first opening the web interface until you're done with it, possibly taking breaks or doing other stuff in between. Whatever pseudo-measure you think works best, go for it.

i dont want you to implement this just to not hurt my feelings^^, but because i think its best for cherrymusic. if you are not convinced, dont implement it. im going for this issue because i think its the best solution, its the feature i love about mpd so much: you can browse your music, create/edit playlists and read the id3 tags when the disk isnt even mounted or connected at all. the database is there already, why shouldnt it be used more? i think its a waste of potential to use the database for fast searches only. why should i be happy about (theoretically) fast search results, when it takes another ~8 sec to spin up the drive plus another ~2 sec for read access. makes no sense to me. but we were at that point somewhere in the discussion above already.

I'd like to get a feeling for how much "wait" there is. I guess I should also spend more time making playlists on the testserver...

yep, dont understand you didnt notice it so far.

[tilboerner]

im still wondering why you are not bothered by this. the testserver has the same setup after all.

I usually just put an album in the queue and let that play. When it's close to running out, I add more; the disk is awake then, so there's just the one wait right at the beginning.

i dont want you to implement this just to not hurt my feelings^^, but because i think its best for cherrymusic.

Don't get me wrong: not that I wouldn't value your feelings, but I'm sticking around because this seems to bother you enough to not let it drop either. What bothers you will bother others. I don't care much for the hard disk and how often it gets woken up; I was after something like the "perceived" number of time-outs per user, how much you have to wait.

An unresponsive interface is bad, because it silently makes you distrust it. That's among the worst things that can happen to a program in my opinion. My take from that: don't make people wait; if you have no choice, it's important to give them immediate feedback, a sense of progress, and to try to make these time-outs predictable. So I think it's tolerable if sometimes the first thing you do in the program takes a little longer; that's something I could make peace with as a user. But if the interface seems to take multi-second breaks at random times: not good.

[devsnd]

Even though I enjoyed this conversation, but we don't have the manpower to do this right now. There are more important things to solve and most users will have a spinning harddrive and not a sleeping one, while using the program. There are multiple reasons for this decision, but there are more to come.

[6arms1leg]

@devsnd is on a issue closing raid again!

There are multiple reasons for this decision, but there are more to come.

can you please be a little more specific?

this is really disappointing. it was the only issue that kept me from using cherrymusic on a day to day basis... i was looking forward to this!

[devsnd]

I won't say that it's not coming sometime later, but there are more important issues right now concerning the user experience of the whole thing. Reasons for me closing this issue right now:

• display of local album art
• Detection of deleted files and automatic db-updates
• Reading Music Meta-Data

I consider these essential features, whereas not spinning up the harddrive isn't one for me, since it needs to spin up anyways if you want to listen to the music.

[6arms1leg]

i understand.

I won't say that it's not coming sometime later, [...]

glad to hear that! :+1: i wont forget about this issue!^^