Playlist opens a very long time

[user623]

Hello.
I have 3400 files in my library.
I set "hello" tag to 500 of them.

Then i create auto playlist "all without hello tag". When i click on it - it take 15-20 second to load and show files.
If i create hello2 tag and also exclude it - playlist open up to 30 seconds. All this time mezzmo "not responding".

And on clients (android mediahome) this playlist does not open at all.

I think it's a bug, please fix it.

UPD: I get this problem only when use play count rule ( Play count -> Is -> 0 ) with tag rule ( Keyword -> does not contain -> hello)

UPD: Category1 and Category2 - 1000 and 300 files
Rules set:

All:
Category -> does not contain -> Category1
Category -> does not contain -> Category2
Play count -> Is -> 0

Make mezzmo "not responding" until shutdown thru process manager.

[Paul]

Thanks for reporting this. We'll reproduce the problem here and fix it up for the next Mezzmo release. You can email us at support [at] conceiva [dot] com and we'll provide you a patch when it's ready.

[JiKo]

Hi,

ever night, when mezzmo update the library the active playlist are very very slow updated (more than 5 h) and mezzmo will use much cpu time. my server goes to 100% cpu. i have more than 16000 mp3 and more than 13000 pics and more than 400 mp4 videos. running mezzmo 4.1.3 and the user interface ist very slow.

:confused:

[Paul]

It's best we see a set of logs. Turn on logging in Mezzmo (see http://forum.conceiva.com/showthread.php/419-FAQ-How-to-turn-on-diagnostic-logging) and restart your Mezzmo server. Exit Mezzmo app and run it again. Now reproduce the slow maintenance/active playlist processing. When completed, stop your Mezzmo server and exit Mezzmo app. Zip up all the logs and email them to us at support [at] conceiva [dot] com.

[user623]

we'll provide you a patch when it's ready.
I get another patch that fix disconnection of transcoded data storage.
I see that the patch - it's two files that need to be replaced.

But if i replace files from second patch - i lose first patch?

[Paul]

The second patch also contains all the fixes from the first patch :).

[ftanner]

Hey Paul. I've noticed that since you switched over to the new interface that it does take quite a bit longer to open than before. I have chalked it up to just being a different interface.

[jbinkley60]

Hey Paul. I've noticed that since you switched over to the new interface that it does take quite a bit longer to open than before. I have chalked it up to just being a different interface.

I've assumed the being slower to the database changes where they pulled the images out of the database into a folder structure because folks were concerned about the database size. A test to see how much a difference it makes is to change your Mezzmo view to Details, which doesn't display the images. For me it is much faster than the icon or thumbnail views.

[Paul]

Hey Paul. I've noticed that since you switched over to the new interface that it does take quite a bit longer to open than before. I have chalked it up to just being a different interface.

Do you mean it's slow to start Mezzmo (Windows) app or when you browse a playlist or folder in Mezzmo (Windows) app? We have not noticed a huge slow down here or had it reported by other users, so it could be something going wrong with your particular Mezzmo setup. We're happy to look to at a set of logs from you to see if we can see anything going wrong. Turn on logging in Mezzmo (see http://forum.conceiva.com/showthread.php/419-FAQ-How-to-turn-on-diagnostic-logging) and restart your Mezzmo server. Exit Mezzmo (Windows) app. Now start it again to reproduce the slow opening. Once reproduced, stop your Mezzmo server and exit Mezzmo (Windows) app. Zip up all the logs and email them to us at support [at] conceiva [dot] com.

[ftanner]

Do you mean it's slow to start Mezzmo (Windows) app or when you browse a playlist or folder in Mezzmo (Windows) app? We have not noticed a huge slow down here or had it reported by other users, so it could be something going wrong with your particular Mezzmo setup. We're happy to look to at a set of logs from you to see if we can see anything going wrong. Turn on logging in Mezzmo (see http://forum.conceiva.com/showthread.php/419-FAQ-How-to-turn-on-diagnostic-logging) and restart your Mezzmo server. Exit Mezzmo (Windows) app. Now start it again to reproduce the slow opening. Once reproduced, stop your Mezzmo server and exit Mezzmo (Windows) app. Zip up all the logs and email them to us at support [at] conceiva [dot] com.

When clicking the Playlist to open it to see the files in the right-hand pane. Like I said, I pretty much chalked it up to being "normal" since it has done it from the very first version with the new interface. It could be because I have the viewing pane set to "small thumbnails" so it has to get the pictures from the database.

[Paul]

Understand. It should not be much slower at all than previous versions. Email us a set of logs as per my previous post and we'll see if there's something going wrong with your setup.

[smitbret]

Same here. For me, the problem seems to be isolated to Active Playlists.

They will take forever (literally hours) to build after you create them and the interface is virtually unusable in the meantime. Often, Mezzmo can be locked up for an hour or two after a new playlist is created. They have also been known to crash my XBMC v13.2 HTPC when I try to access them too soon. The active playlists take 4 or 5 minutes to load on the HTPCs the first time they are accessed. I assume that is just caching of thumbnails and things like that, but I never experienced anything noticeable until Mezzmo v4.

I turned on logging and oddly, the interface was much snappier after I activated logging. It still had delays when accessing the active playlists but these were measurable in seconds or minutes instead of hours. I will zip the logs and send them this afternoon.

I am wondering if my hardware has anything to do with it; WHS 2011 running from an SSD and the media files are stored on a FlexRAID array.

[Paul]

Thanks for the feedback, smitbret. We'll check your logs when we get them to see if we can see anything going wrong.