05
Sep
Jinzora still blows.
I just thought I’d see if Jinzora had made any progress with putting together a good web-based music interface. So, I downloaded and installed jinzora 2.6. The verdict: JINZORA STILL BLOWS!
It hung after spending about an hour importing 2/3 of my music (~16,000 songs). Not much more I can do at this point. Maybe they’ll have a 3.0 release that actually works for music collections of the 25,000 song size.
EDIT: I’m now using Ampache for music serving, and it totally ROCKS.
Well I’m sorry you had trouble with the installer – if you’d stop by our forums and let us know what’s going on we’ll do all we can to get you going. Jinzora, being an enterprise level piece of software, has some pretty strict server requirements, so it’s hard for us to test it in every possible scenario. If you can give us more information I’m sure we can get you going or fix the bug that you encountered…
I certainly don’t want you to think it blows, especially when we have so many very happy users
Just my 2 cents…
Ross
Huh. Is that a hint that my Athlon X2 4400 with 2G RAM running 64-bit Linux isn’t beefy enough for Jinzora?
When I had the hung import, I cheked the forums to see if anyone was complaining about similar issues, and I saw some similar things, but I never saw a definitive “Do X to solve Y” response. Mostly, what I saw was “Try the Nightly Build” followed by “Ok, did that, and it still doesn’t work”.
I guess I’m just overly criticial on this issue, because my install of Netjuke 1.0RC1 works just fine, and yet all effort has gone into Jinzora for the last year(s) and it still hasn’t produced a product thats as good as a Netjuke release candidate was.
I did a little digging to try to figure out what the “real” problem was. I looked in my php log, and found a bazillion of these:
[04-Sep-2006 23:01:48] PHP Notice: Undefined variable: installer in /var/www/html/slacy.com/jinzora2/backend/backends/id3-cache/media.php on line 129
Followed by this:
[04-Sep-2006 23:01:49] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 84 bytes) in /var/www/html/slacy.com/jinzora2/services/services/tagdata/getid3/module.audio.mp3.php on line 1700
So, you’ve got a memory leak. I’ve already got my PHP memory setting boosted to 32M, and I’d really prefer not to have to make it higher (it got through 61% of my music, so I’ll probably need to boost it to 64M to get this right).
Its also possible that your progress indicator for the import is the thing taking up too much RAM (because of PHP output buffering). I’d suggest using a model something like “import 2000 songs, then issue an HTTP redirect to import more, until you finish, then redirect to the ‘done’ page”
Or, have a “background import” feature, although I’ve no idea how this would work in PHP.
Also seeing out of memory issues here:
[05-Sep-2006 10:15:59] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 84 bytes) in /var/www/html/slacy.com/jinzora2/backend/class-element.php on line 58
and
[05-Sep-2006 23:31:24] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 227 bytes) in /var/www/html/slacy.com/jinzora2/services/services/tagdata/getid3/module.audio.mp3.php on line 425
(I guess when you’re out of RAM, its pretty random which function actually puts you over the limit)
I’ve bumped all the php settings *way* up and am trying again. I think you guys should try to figure out a solution that works inside the “normal” PHP settings, which allow for only 8M of RAM, and 30s execution time.
Update: Bumping php’s memory_limit to 128M was *still* not enough to import 26,000 songs! What a memory hog! Thats over 5kB per track! I’ve bumped it to 256M to see if I can actually get a successful import. Oh, and by the way, this also proves that your memory usage is non-linear. I can import 16,000 songs with 32M, and 25,000 songs with 128M. Something’s fishy here, and it isn’t my php.ini
Ok. Import worked. Software is slow as shit, because it *really* wants to display a top page with all ~7500 artists in my collection. This is retarded. Giving up.
I just installed Jinzora with 85,000 songs. Not sure about the memory requirement, had mine at 1024 Megs. Only thing I can say is that Jinzora is SLOW. Sometimes it takes 75 seconds to load the home page and its installed on a real server. Its a dual P3@1.4 ghz with 6 gigs of ram running slackware linux. The same server can handle a mysql index table with 2 million entries with a query time of about 1/4 second. My guess is that the php code isnt very efficient.
I just read a little about this issue on another site..
http://fleshy.org.nz/yum/2007/05/30/jinzora-media-jukebox-impressions/
.. apparently it is a result of jinzora trying to be compatible with too many databases, and using some inefficient database query method..
I have a relatively small collection (7K) running on an AthlonX2-64 2.4Ghz with 4G RAM.. work great for me..
Also, I have also seen posts from people with with larger libraries solve the issue you are having by setting the top / home page to load Genre’s instead of Artists.
I discovered this post while googling for the solution to a Jinzora problem (how to switch to using ID3 tags for metadata after installation–still have no idea) and tried Ampache instead. It’s been doing nicely for at least twelve hours now, so thanks.
For the record, Jinzora has issues. Running on dual 2.4Ghz Xeon system with 8 Gig of ram it took 3 minutes to open the frontpage (even after I cranked my php settings past sane limits). it also pushed my loadavg up past 13. I tried hooking it up to 2T of music (it all lives on a SAN: effective transfer rate from sotrage to hba is 4Gbps) and it performs horribly. Under the same conditions, ampache performs wonderfully. While I was kinda liking jinzora, i still gotta go with ampache for the time being.
20,000 tracks for me, imported fine with the minimum PHP memory setting.
However, I’m running a proper MySQL server, the hard drives are hardware RAIDed, the server is a dual core Xeon 3.2GHz and it has 2GB RAM and the pages are still much slower than I’d like. It’s not a show stopper because it does work, but by no stretch of the imagination could it be called ‘snappy’.