[rsjtdrjgfuzkfg]

(05-05-2013, 03:23 PM)tibitts Wrote: You can probably use the 'Playlist Export' extension for this.

Afaik, that only exports static playlists and static snapshots of dynamic playlists, thus dynamic playlists may get lost.

[3×5]

OK, so I am still using Nightingale and still love it, despite the sluggishness. I have definitely isolated the issue to my high number of smart playists. I have rendered out the ones I can as flat playlists, but I mostly categorize my music collection by adding comma-delimited "hashtags" into the comment field, and then sorting these using smart playlists.

I am runnint 1.12. I am going to try to rebuild my playlists from scratch and see if the problem persists. If anyone knows a way to improve performance with lots of smart playlists, I woul love to hear it. Maybe I could optimize the db somehow? Maybe an upgrade? Anyway, thanks.

[rsjtdrjgfuzkfg]

(03-01-2015, 01:49 AM)3×5 Wrote: Maybe I could optimize the db somehow? Maybe an upgrade? Anyway, thanks.

If you're brave, you could try building with a more recent sqlite, see this pull request. If you do, please leave some feedback!

[3×5]

OK, I've isolated the problem even further. I think the program itself runs OK, and the boot time isn't so bad. It's the synchronization page that's painfully slow. And I assumed this was because of a high number of smart playlists, but I have found that as long as I'm syncing a large library (~7,000 songs), even if it's syncing no playlists and just the whole library, the whole thing is so slow you can barely use it. I assume this is true of everyone. Is that the case?

[rsjtdrjgfuzkfg]

(03-26-2015, 01:47 AM)3×5 Wrote: It's the synchronization page that's painfully slow. And I assumed this was because of a high number of smart playlists, but I have found that as long as I'm syncing a large library (~7,000 songs), even if it's syncing no playlists and just the whole library, the whole thing is so slow you can barely use it.

I do not really understand what you mean. Possible interpretations that came to my mind:

• While a sync is in progress in the background, other parts of Nightingale are slow (playback controls, organizing songs, updating metadata, browsing, ...)
  
• Actions within the synchronization tab are slow (expanding/collapsing the profile panel, clicking buttons). Note that selecting and deselecting playlists is known to be slow, as the total size is not cached (thus, these operations perform some heavy I/O, which is slow depending on your HDD/SSD speed and library size).
  
• Once a sync is started, it takes a long time to complete
  
• Nightingale is slow, independently of background synchronization or whether the synchronization tab is open or not, but disabling synchronization internally (by deleting the corresponding internal add-ons) causes Nightingale to be fast again.
  

Does one of these points fit to your problem, or is it something completely different?

[3×5]

Sorry for being so vague. When I get to the synchronization page, the interface is not very responsive. Checking or unchecking playlists to add to the library, editing other synchronization settings, this is all very slow. And then, when actually going to sync, the synchronization process is pretty slow as well. But mostly, it's that process of including playlists and setting paths that so painfully slow. I hope that's clearer.

[rsjtdrjgfuzkfg]

(03-27-2015, 01:40 AM)3×5 Wrote: Sorry for being so vague. When I get to the synchronization page, the interface is not very responsive. Checking or unchecking playlists to add to the library, editing other synchronization settings, this is all very slow. And then, when actually going to sync, the synchronization process is pretty slow as well. But mostly, it's that process of including playlists and setting paths that so painfully slow. I hope that's clearer.

That's weird. While "Checking or unchecking playlists to add to the library" is slow due to the reasons I mentioned in the last post (in my case up to 6 seconds unresponsiveness per click), all other parts should not really be slower than any other component of Nightingale. With my ~2.7k Library (~65 GiB) I was not able to reproduce that issue, but it seems that yours is somewhat larger...

Do you get messages in the error console or similar signs of something going terribly wrong? Did you build by yourself or are you using one of the official release builds?

[3×5]

Hi, thanks for the response and sorry for the very slow reply.

The error console does indeed provide a clue. Checking and unchecking playlists are the biggest issue. I will click a few and there won't be that much lag, but then it will really hang up on one. When this happens, my CPU usage goes way up and the console gets flooded with the same message:

[Javascript Error: "too much recursion" {file: "file:///usr/share/nightingale/components/sbParserError.js" line:38}]

[rsjtdrjgfuzkfg]

(07-29-2016, 08:46 AM)3×5 Wrote: [Javascript Error: "too much recursion" {file: "file:///usr/share/nightingale/components/sbParserError.js" line:38}]

The message immediately before this error may be of relevance. While I haven't looked into the Mozilla code for the error console, these errors seem like a symptom, not the case for the issue (the line the error occurs at is run for each entry in the error console, thus if the error occurs once, it causes itself to be called again. The true issue is that the message immediately preceding it seems to exhaust the recursion limit - that's likely the actual issue one would need to fix).

If you don't need the selection size on the left of the playlist selection, you could delete all code from the function calcSize within accesspane.js (in built versions: unzip extensions/foldersync@rsjtdrjgfuzkfg.com/chrome/foldersync.jar to find the file) in the FolderSync extension (which is bundled with Nightingale, technically providing the synchronization feature). Not nice, but it might work around your issues.