In my customized older version of IDJC, I added a new tab in the P3 view to sort by album. I find it very handy when I'm looking for songs that are on compilation or soundtrack albums. I remember which album the song is on, but not always the artist.
If there is interest, I'll work my custom code into the current development version. (I'm going to do this anyways, because I can't live without this, but I think it would be a nice addition anyways)
It's better if you wait a few days due to a complete rewrite of p3db.py on branch feat/songdb as songdb.py. I have the tree view working and it no longer freezes on large databases.
The rewritten database code has been merged into master. It looks promising so far.
Just checked it out, looks and seems so far to work great! Thanks! No more hanging when connecting to the database.
I've just noticed a small problem. Every time you connect to the ampache database, the FULLTEXT search index is added again. Looking at the new code, it looks like you are just adding the index on every connect.
Other than that, my testing looks like the new code is great!
I did file a new unrelated bug report about playing ogg files.
Keep up the great work!
In the new code the query explicitly states the name to use for index key which will result in a failure response from the server if the index key is in use. Your concern is therefore unfounded.
Ah, it must have been something that I did. But there is still a problem. I removed all the FULLTEXT indexes in my database and reconnected with IDJC. Now the indexes are not being re-created.
It looks like the default ampache database already has keys in the album and artist tables named 'name', so when you are creating the fulltext key name, it fails.
I changed the key creation to "ALTER TABLE album ADD FULLTEXT albumname (name)" and "ALTER TABLE artist ADD FULLTEXT artistname (name)" and now everything works fine.
I must have deleted the regular index originally put there by Ampache allowing IDJC to write the fulltext index.
I have altered my code to use idjc as the fulltext key on Ampache databases.
I have just pushed the Album - Artist - Title code to master.
Hmm, I had already added my version of an Album view, but I took a different approach. I created a seperate album view, and did a Album - Disk - Artist view (sorted by track #, so they show in order of the track, not artist).
I did this before you pushed your changes, so I'm not putting a patch up yet, since I don't know what that may do to your code if you try it.
Here is a screenshot of what my version looks like: http://millham.net/images/idjc-album-view.png
A few notes about what I did. I do a second query to the database to get the album info. If an album has no disk number associated with it, then expanding the album shows the tracks, instead of just Disk 0. If there is just one disk, it will show Disk 1. (I'd like to make that behave just like if there is no disk, but I haven't worked on that yet)
I do like the idea that you impemented where instead of a new view, the album view is a selection. I haven't looked at how to combine the 2 ideas yet.
I'll see if I can figure out how to create a patch based from the point where I created my local branch, before I updated with your latest update (I'm not that good with git )
Do P3 databases even contain disk numbers? I am forcing 0 for P3 at the moment.
Separate lookups are slower than resorting the data.
The Abum tab doesn't communicate the heirarchy fully or what it does or is - it's not an album.
Tree and Flat should be Browse and Search. The user is thinking of an activity, not set theory.
Albums tagged Greatest Hits for album name will clash. That's why I made artist be secondary. Many multi-albums have the disk number in the album tag so you would get in your album view 'The Wall -_>Disk 1-_>. This would look superfluous to the user.
No, the P3 database does not have disk numbers.
Actually, I just tested, and while 2 querys are slower than one, the resorting is very slow (on my 39,974 track library). Some rough numbers:
With my code:
Time to execute database querys: 1m30s
Time to populate album tree: 20s
Time to populate artist tree: 45s (these are actually done concurrently, so the total time to populate is 45s)
With your code:
Query: 30s (much better)
Populate: 13m30s (WOW!)
I've often wondered about the choice of Tree and Flat. In my modified version, I call them Artist/Album/Search, but as you said, Browse may be a better term.
As to Greatest hits, the Ampache database actually takes care of that for properly tagged tracks. See this: http://millham.net/images/idjc-bestof.png
What I do in the query is return a new row (row) with the ampache album id. While populating the treeview, instead of using the album name, I'm using the album id to detect a change of album. With ampache, 2 albums can have the same name, but will have different IDs.
As what you point out The Wall . Yes, that's a problem in my database, but in my opinion, it's improper tagging. I've cleaned up a lot of those problems. The proper tag should be The Wall.
Also, I haven't worked on this part yet, but if there is only 1 album instead of what I currently do (Album -> Disk # ->) I'm planning on doing like I do if there is no (or 0) disk number (Album -> tracks)
So the view is a little different depending on the album, but it's like browsing a real physical cd. Single CD's just list tracks, multi CD sets list Disk -> Tracks.
My code does not currently support P3, since it doesn't have album ids, but I have an idea to take care of that. (BTW, I've completely abandoned my use of P3 :D. My website that my listeners can make requests on and browse my library is now using the ampache database)
I fixed my code. 55 seconds for the initial fetch and populate with the remote P3 database you provided. Add another 15 seconds for subsequent due to the store having had set a sort column (previous code contains a bug where full sorting is re-added resulting in that insane 13m30s). Really the sorted store should be renewed on each read.
Warning: there is a GTK out of sequence code execution bug prior to f366546b4… which will crash IDJC hard when it strikes.
I see the merit of your ordering scheme having witnessed the mess mine makes of multi artist compilation albums. I am thinking along the lines of Album - - Title. In this mode the Disk column is replaced with Artist. Duplicate album names would be differentiated by album id as you have specified.
Does the out of sequence bug cause a crash when doing a search in flat mode? If so, I've seen it :D
That's it and if you trigger tree refresh enough times it will happen there also.
Testing on album.id can be problematic for if some tracks in the album have album.year filled in but others have it left blank they generate separate album entries. It can be used to short circuit deeper testing but the time saved is lost many times over in download time.
Times in dev branch reduced to fetch 15s fill 20s for both P3 and Ampache. My PC is 5 years old so a fill time of 8 seconds is not impossible.
My personal preference would to be to use the album.id, and instead of trying to merge things in IDJC, leave it up to the user to correct their library, so they get the correct results. I've been going through my library taking care of the year problem that you mention, and it's looking much better.
As a side note, did you get my e-mail with the access info for my ampache database?
I have a couple of ideas that I'd like to chat with you about; would you prefer that we do that here (in a new thread) or via e-mail?
I replied to the ampache database email so maybe the reply address is not monitored? I think this forum (not necessarily this thread) is the better place for discussion so that others may participate.
Here is where my code is at. Albums have the album year alongside if present (both views).
In album view, tracks will be added until the album id is different then we check if the album name or year is different which leads to a new album node being added. If no new album node is needed a check is done on the disk number with 0 not having a node and tracks are added under the album node otherwise a disk node is added and tracks added under that. This means that two albums can appear under the same album node if the name and year are the same but they will be separate e.g. first album tracks 1 to x followed by second album track 1 to y rather than intermixed as happened previously.
I decided to get rid of multiselect for drag and drop in the Browse view. This prevents confusion caused by the ability to select parent nodes along with some or all its children. It also makes dragging and dropping easier and faster.
Just checked out the latest changes and WOW, what a difference! I didn't time it, but much improved!
I like the new select behavior. Much better.
There's only one little change that I'd ask for: Honoring the album and artist prefix in ampache. Maybe it's just a personal preference for me, but I'd rather see "The Rolling Stones" listed under R rather that T. There are just to many "The"… Same for albums.
There is a bug however. Clicking on the refresh button causes this error:
Song title database: Tree fetch failed
Song title database: Problem dropping connection
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/idjc/gtkstuff.py", line 179, in newf
r = f(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/idjc/songdb.py", line 800, in _update_2
rows = cursor.fetchmany(do_max)
File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 336, in fetchmany
File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 80, in _check_executed
self.errorhandler(self, ProgrammingError, "execute() first")
File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
_mysql_exceptions.ProgrammingError: execute() first
I see that you changed artist sorting to drop the prefix, thanks! But albums still use the prefix for sorting.
I've started work on the Request tab :D
Fixing the album sort order requires some structural changes that I didn't have the time for.
I'll work on album sorting, it doesn't look like it should be to difficult (I could be wrong, as I just started looking at the code :D)
Log in to post a comment.