I was keeping a vector of objects, and then pass pointers to these
objects around everywhere. HOWEVER, when vectors are resized they
allocate new memory and copy things over invalidating iterators and
pointers to the original objects. This can cause memory corruption
issues when I try to use a pointer to an object that no longer exists.
The simple solution? Allocate tracks dynamically and then store the
pointer in the library path.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I want to remove the various idle task types that have built up and
replace everything with a single idle type. I also want the idle layer
to be the only place new tasks are allocated.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Now that I'm using vectors for everything I don't need to maintain my
own class. Nothing uses it now, so it can be safely removed.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
For each library path, I replace the linked list with a vector allowing
me to easily index into the list to find tracks.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
This corrects the package build to look for a tarbal named
"ocarina-5.11.1.tar.gz" instead of "ocarina-5.11.tar.gz"
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Otherwise songs might error out part way through playing and skip to
something else. It doesn't make sense and I wish I knew why :(
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
The vector should be simpler than a linked list for tracking playlists.
I also changed reading playlists to use a function in the playlist class
rather than a function outside of the playlist.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I'm going to gradually move this out of the playlist/ directory since it
doesn't really belong there. I also plan on cleaning up / rewriting
much of the code as I go along.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I plan on removing this class in favor STL classes. I probably
shouldn't have even tried to implement this myself...
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Most of this was commented out and hasn't been used in almost a year.
The new gstreamer code doesn't have the property probe feature anymore,
so I can't reimplement my old alsa code. I'll drop it for now and
figure it out later (after cleaning up this other code).
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
When scrolling I think it's important to show a few rows that are coming
up next so users know they can stop scrolling and not need to reverse.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Gstreamer 1.0 has been out for a while and replaces gstreamer 0.10.
Let's make sure we use the most recent version going forward.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I used to use my own inverted index implementation, which makes sense if
I'm searching all songs for a specific match. Instead, GTK was visiting
each track and asking "does this song match?" and this requires a
different implementation. So rather than make an index, instead I have
each track generate substrings for its tags and then I compare filter
text against the substring set.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I also replace a few PLAYLIST_* notifications with a generic
PLAYLIST_CHANGED notification for when small changes occur. I think
that using set_flag() and check_flag() will make code cleaner and easier
to maintain.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I don't want to keep one function in a file by itself. Instead, let's
just move it into the main playlist file.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
My "insert while sorted" code was getting complicated, and didn't send
all the notifications to the UI (only the first ~1200 songs were
displayed). This patch both simplifies the code and produces the right
answer without a noticable performance penalty.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I can make this simplier by simply passing the index into the vector,
rather than needing to calculate the iterator and pass the index.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
There is no reason to track this on my own, iterating over all tracks
and calculating it on the fly is easier and basically unnoticable.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I don't need to iterate through a linked list to find the track anymore.
Instead, I can access tracks directly using an index.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I know what playlists are library, recent and banned. All others are
just named "Playlist" so there is no need to set up a name variable.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Vectors are more straightforward than linked lists and they should allow
me to clean up the code a lot. For now I just put in the straight
conversion, I'll clean things up in future patches.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I didn't realize this was still around. It should be removed since I
switched to a notification system instead of using the renderer.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
This finishes the job I started in the last commit. Once again, I use
an enum of string properties to determine the right field to return.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Rathen than using a bunch of get_PROPERTY_NAME() functions, I think it's
cleaner to use dictionary-like indexing to access properties. This
patch converts most track access functions, but I haven't gotten around
to strings yet.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I also respond to the PLAYLIST_SORTED notification so we do the right
thing when loading a playlist during startup. I don't put the sort
button on the library, recent list or banned list because I don't think
these lists should ever be sorted.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Bryan Schumaker
Bryan Schumaker