If you have ideas for how to make IMMS better, post them here.

• Sending an email to the Mailing List is probably a faster way to get your question answered
• Make sure you check the To Do List, and read the Frequently Asked Questions first

New

(add to top or add to bottom?)

• (10/11/2008) - My biggest wish is to be able to treat some songs as a "fixed set". Always play songs X Y and Z together and always start at X if X, Y or Z is "selected" by IMMS.

• If IMMS does not already support this, I think it should rate the song on what percentage of the song actually got played.. (IE. if a song is skipped within a few seconds of being played it will have a lower rating than that of a song that was played through 75%) This should make the program more intelligent. --spacecadet01

• Day of week and/or time of day weighting: i'm much more likely to want to listen to Chris Tomlin than Aerosmith on Sunday morning as i get ready to go to church. :-)

• I know that in the XMMS plugin there is an option to have it keep track of the X idle time, but with my very special computer setup I run XMMS on a slave machine that is never allowed to idle except on express command from me. As such it would be real nice if imms could keep track of when the last user activity related to imms happened and have that influence if song ratings should change or not. When I wake up in the morning I allways find that all songs played during the night have recieved a +2 rating which doesn't feel at all like what I am after.
  • Simple solution - don't leave XMMS playing all night! There's an XMMS plugin called xmms-goodnight (http://fiktiv.szgtikol.kando.hu/~folti/src(approve sites)) that will shut down XMMS at a specified time.
  • Harder solution - involves code modification. Email me with the version you are using and I'll tell you what to do if you're interested. --mag

• Wish I could do more than just suggest ideas, but here's another one. New songs are initially rated as the average of the songs in it's current location or similar locations. The first time /A/B/C/e.ogg is played it defaults to the current rating of it's parent directory C (which is calculate as the average of [a-d].ogg and the ratings of it's subdirectories D (/A/B/C/D) and E (/A/B/C/E. So e = C = a+b+c+d+D+E/6. When songs are updated, it's parent directory ratings are recalculated but only based on their immediate children so A, B, and C are updated but not /A/G. When a new directory is added it's value is set to the rating of it's parent. I hope this makes sense not exactly well explained or easy to explain in plain txt. I realise you said you didn't have time to work on it but just thought I'd bang it up here incase anyone else was up for the job (Probably make a good final year project for a student or something).

• How about giving IMMS the ability to pick `n` future songs ahead of time. So that with the new funky library functions we could tie in a gdesklet or something which would display the next 5 songs to play, you could then skip songs from that list (and have replacements selected) instead of having to wait for the song to be chosen in the playlist and then skipping. --and
  • It's possible, but CPU intensive, because you will have to re-select all 5 every time you skip anything. --mag

• I've got IMMS databases for both home and work systems. Now I have a laptop, and intend to use it exclusively for playing music. Each has some songs the other doesn't have. Both have a great deal of songs in common, too. A generic utility to merge one database into another would be great -- add the missing songs, and average (or weighted average) the common ones. - wisq
  • I can see how this is a good idea, but it's really hard to implement generically. Maybe if the shared songs are exactly identical - aka have the same checksum (this is the case for you, right?), we can do something clever like a database diff/patch utility. But otherwise, it will have to wait until IMMS is a lot more clever about identifying songs. -- mag

  • Actually, upon more careful consideration, I think the solution is pretty easy. All I need to do is keep a "journal" of songs played in the last n days. Then write a simple utility to integrate such a journal into another database. --mag

• Make xmms and imms use 0% cputime when xmms is not playing anything (stopped). Maybe this is impossible due to awful design (of xmms), but currently I need to manually disable imms when stopping xmms, or both will use around 3% cputime forever. --Joshua Rodman?

• Shrink the window during which imms misunderstands actions. Currently, if press Next track in the first second or so (while imms is busily computing and picking the next track), imms will decide I have jumped to the next track explicitly, which I suppose it is just htat xmms's normal random jump feature was applied. --Joshua Rodman?

Rejected

• Time of year and/or title keyword weighting: when it's coming up to Christmas, i love Christmas carols, but in general i prefer not to listen to them year-round. Similarly, i'm much more likely to want to hear songs with the words cross, sacrifice, or lamb in their titles around Easter time.
  • Time of year weighting would take several years to learn. I don't think it's worth the effort to implement this :P
  • As for keyword weigting - it's against the IMMS philosopy... See below.

• What about profiles? Select a profile in a drop-down list (very easy to do it, even in a bash script), then update song probabilities for that profile. Eg. rock, pop, techno, hip-hop, etc. --lorro
  • This will never happen because it is against IMMS philosophy. What is the IMMS philosophy? I think it was best put by my ex-boss, Avery Pennarun: "If it relies on user input, it will not work." Here's how this works:

  Problem: The song ratings are not absolute. They are dependent on the user's mood/current genre preference/etc.

  Wrong approach: Create different profiles so that the user can train, say, a rock and a techno profile separately.

  What's wrong with this solution? Nothing. Except it will not work. Why? Suppose you are playing rock songs, and your all time favourite techno song comes on. What are you going to do? Skip it? Remember to change the profiles? Unlikely...

  So what's the correct solution? Anything that does not rely on the user input :) We can remember which songs are skipped when played consecutively, we can do some fancy sound analysis to try to guess song similarity based on bpm/frequency spectrum, etc. Of course this approach will never be 100% perfect, but, trust me, in the end, it will be better than the alternative.

  Remember, if you want full manual control over your playlists, you could just disable IMMS. --mag

  • Well, I think IMMS/XMMS already has this feature! Just make playlists one with rock, one with techno, etc. To select one of them just load that list.. Want to listen to a mixture of both? Then "cat" them together ("cat rock.pls techno.pls > all.pls") and load that playlist. --adamkl
    • Or just play both: xmms --enqueue rock.pls techno.pls --Joshua Rodman?

Done

• 3.1.0

• On my system, immsd sometimes uses enough cputime (or perhaps iotime?) to cause the music replay to dropout. This kind of defeats the whole point of imms, in providing a pleasant music replay experience. Good queueing is not as important as replay without dropouts. Reniceing the immsd thread to 2 (mostly) resolves the issue. I would like to suggest a fixed or configurable immsd nice value, similar to the reasonably larger values used for sox and analyzer. --Joshua Rodman?
  • I've never seen that. Are you sure your DMA is on? Anyway, you could easily make a wrapper script for immsd to start it an arbitrary nice level. --mag
    • The IDE controller says it is using DMA, and throughput figures support this. The dropouts generally occur when at least one very CPU-hungry process is running, and immsd seems sufficient to push it over the top. I suppose the core problem is that I really want to make xmms's decode thread higher priority than all others, but every time I look into realtime priorities and whatnot they seem a big hairy mess. Also xmms with its plugins tends to run off thrashing semi-regularly, so I'm not excited about it. Your suggestion of a wrapper script is of course workable, and I've already done similar. However, I think your choice of running sox and analyzer at non-default nice levels demonstrates that achieving rational CPU apportionment is in the design goals of IMMS. I think it should be extended to the immsd activity itself. --Joshua Rodman?

• 3.0

• Tweaking of rating adjustments. As there is a maximum rating of 150 it would be nice if IMMS would give lower rating increases for high rated songs. As it is now many of my songs end up at top rating and some of the wanted distinction get lost. Also a high rated song being skipped outh to be decreased more than a low rated being skipped. This would add more of dynamic to the rating and allow forgotten songs to be rediscovered and climb to the top list.
  • The new rating system should solve this --mag

• 2.0

• I would like using XMMS/IMMS to fall asleep at night and wake up in the morning. I'm not able to switch songs then, but this isn't much of a problem since I listen to music longer during the day. The main problem is that I need "calm" music to fall asleep and "faster" music to wake up more easally. This would need some analysis of the music rather than rating from the user. Well, I guess this would be a lot of work, but I'll but it for way in the future nether the less. --adamkl
  • More magic is in the works. It's actually mostly done now.... Just needs some finishing, but free time and inclination have been in short supply lately. --mag

  • Ok, this should be a little more magical now. Just jump to a "slow" or a "fast" song and IMMS will try to select songs that follow suit. --mag

• It would be nice if you could generate a 'similar/compatible songs' playlist with IMMS, of a specified length. Nice to load your minidiscs or mp3players with. -- Ardanwen
  • Similar is pretty tricky... But check out IMFavourites. --mag

• IMMS seems to take a while to switch to the next song and maxes out the cpu for a good few seconds. This is probably to do with the size of the db (and being sqlite) but would it be possible to background some of the process, so it selects the next song to play first then does any updates as a low priority process. Plus are there any docs on the algorithm imms uses apart from the src? [Edit: I may have been a little premature.. just install 1.1 and seems to be much better] -- and
  • Moreover, starting up xmms even with a managable set of files can take 30-40 seconds before the cpu usage drops from "high". It seems well-behaved in that the cpu usage doesn't rise above 40-50%, but the xmms interface itself is not very responsive during this period. Not sure what to suggest, but it would certainly be nice if this cost could be cleanly amortized to allow xmms to remain responsive [Edit: note this is with 1.1] --Joshua Rodman?
    • Long answer: There are two different issues here. One is the cpu usage on startup. Yeah, I know it lags XMMS down quite a bit right now (and it is somewhat amortized). To address this I have to move the core of IMMS into a separate daemon, and I haven't gotten around to working on that yet. The cpu usage in between songs is a totally different beast. I would guess that it is not actually blocking cpu usage - aka it actually has the next song selected and starts it playing before it does anything. After that it goes on to do some updates and select the next song. This can be made to be less noticable, but the again it will be easier to do when it's in a process of it's own.
    • Short answer: if music playing blocks for a long time - complain. Otherwise wait for the next version :) --mag
      • This should be fixed as of 2.0. Comments?? --mag
        • So far, this does seem to be much better with 2.0 (just started using imms again) --Joshua Rodman?

• It'll be nice to logically split plugin into 2 parts: one with player interface and second with the song selecting mechanism to get writting interface for other players as easy as possible ;)

• 1.0
  • The back button doesn't bring me back to the previous song *played*, but the previous song in the playlist. Now I know that it's probably because the plugin interface sucks, as mentionned above, but it's still an annoyance. - The Anarcat

  • The next button seems to work in an odd way: it goes to the next song in the playlist, then jumps to the "real" next song. When using other plugins such as the OSD plugin, it gives bizarre output: a song name shows up for a split second and is replaced. It's annoying. I sometimes skip a song by mistake because of that split second where I think "not this one", when it's only the "false" next song showing up in the display... - The Anarcat