Tagalicious 1.2b4 (last beta before release)

[simX]

Hey all --

I've got a new beta of Tagalicious for you. Version 1.2b4 is
available at http://files.thelittleappfactory.com/tagalicious/Tagalicious_1.2b4.zip
. This beta expires on April 18.

There are only two changes:

• limits the number of simultaneous operations that need access to the
internet (tag lookup, art lookup, lyrics lookup, image retrieval,
etc.) to limit CPU usage under situations where the internet
connection is spotty
• fixes 10.7 support

Please test out this beta and let me know if tagging is too slow or if
it takes up too much CPU usage. Thanks!

-- Simone

[Sean Purdon]

Hey,

The number of simultaneous operations fix doesn't seem to have worked; it's making things worse =(

I tested by looking up the tags for ~250 songs.  CPU use immediately jumped to 100% of both cores, and stayed there for a minute or so.  CPU usage remained reasonable after that (slight spikes to ~30%, but that's okay).

However, tagging is now *much* slower (I'm talking about 10x slower).  I'm watching my download rate in istat menus as I write this, and it's clearly spiking, then settling down at near-zero speeds.  

At one point, it spiked to ~350kB/s for a few seconds, and tagged a heap of songs; no idea why, though, as it then slowed down again.  These spikes/drops correspond very closely with the CPU usage of Tagalicious - when it's not using much CPU, nothing is being downloaded, and no new songs are being tagged.

How is the congestion monitoring/prevention being implemented?  It almost seems to me like it's loading a heap of data from disk, processing the current tags, sending that off to the server, getting a very quick response, then making a cup of tea while it waits for its cooldown timer to run out.

[simX]

Sean:

Thanks for the feedback. It appears that our music database is
currently suffering some reliability issues, which may explain the
problems you're seeing. Yesterday, in particular, the database had
~30% downtime, and we've seen ~15% downtime today too. (Even when
requests to the database succeed, they are often slow.)

There's no real "congestion monitoring", there's just now a limit on
the number of simultaneous requests issued to any online sources. So
if there are 40 requests to something on the internet, and they're all
going slow or haven't responded, Tagalicious now waits until it
receives a response or a timeout from the server before issuing any
new requests to another online source, rather than continuing to issue
new requests to the servers (as it did in 1.2b3 and below).

The spike of 100% CPU usage at the start is probably normal, because
Tagalicious has to actually read the audio files from disk the first
time you request tags. It's likely that after that minute, it has
already finished reading all of your 250 songs from disk, at which
point it's simply retrieving data from internet sources, which is far
less taxing on the CPU (especially if it's just sitting their waiting
for responses). Although it's possible that the CPU usage during
audio file reading is unacceptable, and I should drop the limit of
simultaneous audio reads back down to 1 -- was your Mac responsive
while trying to do stuff in other applications during that first
minute?

I'll let you know when the database reliability problems are fixed.

-- Simone

[Sean Purdon]

Hey,

The spike to 100% CPU usage at the start was fine, especially given that it was only for a very limited time.  I think the people it effects (those with SSDs) won't worry too much about it, because it's over fast, and those who it would cause problems for because of the time taken to read the tags (people with conventional HDDs) won't see the usage spike because they won't be reading as many tags at once.

I didn't notice any responsiveness issues.  Let me know when the database is a bit more stable and I can do the test again :)

[simX]

Sean: the database reliability problems seem to have been stabilized.
Could you retest and check to see if Tagalicious is running normally
again?

Everyone else: please test!

-- Simone

On 11 Apr, 15:46, Sean Purdon <sean.pur...@gmail.com> wrote:
> Hey,
>

[simX]

*crickets*

I've extended the beta to May 2 at the same URL:
http://files.thelittleappfactory.com/tagalicious/Tagalicious_1.2b4.zip
.

Has anybody tested this beta?

-- Simone

[Sean Purdon]

Hey sim,

I'm away camping without a computer, should be back tomorrow some time.  I'll give the beta a look then.

cheers,

sean

[Sean Purdon]

Turns out we stayed a fair bit longer than expected, sorry bout the delay :(

I've had a chance to test the current version, but unfortunately not the beta, despite the extension.

CPU use on the production version was quite similar to that of the latest beta I tested - hovering around ~125%.  Tagging felt much slower, and was certainly nowhere near as quick as on the initial 1.2 betas (the ones that exhibited runaway CPU use).

I'm surprised at the amount of CPU it's using given that it's not nearly as multithreaded (and is hitting the disk constantly over time).  I'd say there's a definite efficiency improvement in that regard in 1.2.

Cheers,

sean

[simX]

Sean:

I've extended the 1.2b4 beta by another two weeks, find it at the same
URL. Please test CPU usage on that one, too. Thanks!

-- Simone

[Sean Purdon]

Simone,

The 1.24b4 build tags significantly faster than the current app store version.  You can really tell that the multithreading is working.

I monitored CPU and disk usage during a batch 'get tags' operation.  CPU usage sat at about 100% of both cores, and disk usage was high (reading at probably 10MB/s average, spiking to 30MB/s once or twice) for as long as the operation was being processed (when the app had finished getting tags for each track, both dropped right down).

[simX]

Sean:

Was the rest of your computer usable during the time that Tagalicious
is using 100% of both cores? (If you start trying to do anything else
processor intensive in other apps, Tagalicious's CPU usage should drop
enough to allow those apps to do things responsively.)

-- Simone

[Sean Purdon]

Simone,

Yep, it was certainly usable.  Less responsive than normal, but not to an extent that really inhibits use.