Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BryanC]

JRMark:

• Math: 4188
• Image: 7395
• Database: 2765 ('Search Database' takes over 4 seconds')

I thought it could be related to CoW (btrfs) but there aren't many writes in ~/.jriver so not sure if nocow or noatime are relevant.

I'm sending a library backup and logs from when I click around on items with the tag editing window open.

[HaWi]

I see very sluggish scrolling on both the Synology and the rPi4 (even when the tags window is not open), to the point where it is not feasible to any editing at all. Constant freezes last many seconds.

[bob]

Can you detail steps to reproduce this on a standard platform (not NAS)?
Also what build did you notice this behavior starting and what build are you using now??

I'm not seeing it.

[BryanC]

Can you detail steps to reproduce this on a standard platform (not NAS)?
Also what build did you notice this behavior starting and what build are you using now??

I'm not seeing it.

I sent a library backup to logs@jriver.com. I'm on my desktop, no NAS involved. MC and  database are on an NVMe drive and the library (files) are stored on a RAID1c3 spinning rust btrfs array.

In Movies standard view>select a movie thumbnail>Alt+Enter to open tag window>Click another movie thumbnail, the whole UI will be unresponsive for about 5 seconds and then the tag editor window will finally show the details for the newly selected item. This happens every time I try to select a file with the Tag Editor window open.

If you cannot reproduce, my hunch is that it's a CoW performance issue since we're dealing with a database.

[JimH]

Client/server?

Or network drive?

[BryanC]

I'm working locally on the server, no network drives, all SATA or NVMe.

Also what build did you notice this behavior starting and what build are you using now??

Missed this. I'm using 28.0.81, I first noticed it a few point releases ago, but I've also been importing a lot of new items (more than normal) into the library so not sure if that was what triggered it. If I had to say, I think the sluggishness has been getting worse I've grown the library.

[HaWi]

Sorry to say but 28.0.81 is even less responsive on the rPi4 than .79 or .80. The last good one was .73
BTW, the benchmark values haven't changed significantly between .73 and .81

[bob]

Sorry to say but 28.0.81 is even less responsive on the rPi4 than .79 or .80. The last good one was .73
BTW, the benchmark values haven't changed significantly between .73 and .81

Thanks that version info helps.
It's quite a bit faster and less jerky for me on AMD64.

[HaWi]

Thanks that version info helps.
It's quite a bit faster and less jerky for me on AMD64.

I realize that the rPi4 and the Synology have crappy CPUs so they weren't performing great from the get-go but scrolling has deteriorated significantly since .73
On the iMac and MacBook Pro on the other hand scrolling has improved a lot. Much smoother now and everything feels snappier since .79 with small improvements in .80 and .81 (just by feel)

[JimH]

Does build 73 still work as expected?

[HaWi]

Does build 73 still work as expected?

yes, it does

[BryanC]

28.0.73 isn't nearly as sluggish, although it's still not as fast I hope it can be.

[bob]

Got a new one coming in the next hour or so that seems to fix the issue.

[BryanC]

28.0.83 is much better!

[bob]

28.0.83 is much better!

I thought so as well.
It seems to me to be more responsive than any previous version.

[HaWi]

28.0.83 is much better!

Agreed. On the rPi4, scrolling is now back to about the same as .73, possibly even better.

[mwillems]

The latest build is much more responsive, and it solved a long-standing UI quirk of the linux versions where fast scrolling would sometimes create several seconds of input lag.  Now if I hurl the scroll wheel, I can start scrolling in the opposite direction to stop the scroll momentum almost immediately (just like Windows).   Great stuff!

[HaWi]

The docker version is also now much more responsive. However, and this may just be due to my setup, when the tag window is open, scrolling through a panel is slow and switching focus between tag window and panel is a bit painful as the tag window is still scrolling and the panel unresponsive, and vice versa. It's back to being useful though.

[BryanC]

I resolved the majority of my remaining performance issues in MC by mounting my BTRFS media drives with noatime. This prevents an unnecessary CoW whenever MC (tag editor?) accesses a file for the first time within a 24 hour period.

[BryanC]

I'm running into performance issues again, even with noatime. It's amplified about five-fold whenever the tag editor is open. When I'm on a Media Server client, I don't have any issues (only locally on the server) so I don't think the library is the issue. Clicking around on various fields can take as long as 3 or 4 seconds to register when the tag editor is open. Pane tagging OTOH feels just as fast as I would expect it to.

Btrfs CoW + databases is not a good combo but the system drive is a super fast NVMe that I think would mask any performance problems if this were the culprit.

My actual media library is on a 9 drive Btrfs RAID1 array that benchmarks at around 350 MB/s read/write in other applications so it isn't a slump either. But I can imagine that a lot of non-sequential reads (like loading bulk metadata from files) could be a bottleneck. But, presumably this shouldn't be happening just clicking around the UI.

I haven't had this problem on other filesystems on Linux so it's definitely a Btrfs thing, I just wish I knew whether this was caused by the MC database on my system drive or by MC accessing (and thus CoW'ing) my media files when the tag editor is open. Since this doesn't happen on an MC client I'm guessing there is some disk operation occurring in the local instance that is handled in memory by the database on clients.

[mwillems]

So a datapoint I can offer you is that all of my media files are on a BTRFS drive with COW enabled, but my JRiver database is on a normal EXT4 filesystem on my server.  I experience no slowdowns when tagging ever.  That leads me to suspect you're encountering issues with the database and BTRFS.  My understanding is that clients download the server's database once on initial connect and keep it in memory (and if you have auto sync enabled they sync up periodically) so that's more support for server database disk access being the culprit.

Have you tried turning COW off for the JRiver database directory?  It's trivial to do, and the COW performance penalty for databases/VMs is pretty intense.  My understanding is that it can  also (or at least it used to be able to) cause corruption. I haven't tried running a VM or Db on BTRFS in a few years, but the last time I tried to run a VM on a BTRFS drive with COW enabled it was semi-unusable. So now I always follow the stock advice and either disable COW for relevant directories or just stored my databases/VMs on non-BTRFS filesystems.

[BryanC]

Thanks and oh duh, I had disabled CoW for my MC28 directories specifically ("~/.jriver/Media Center 28" and "/usr/lib/jriver/Media Center 28"), but not the parents ("~/.jriver" and "/usr/lib/jriver") so subsequent MC version installations (the beta) reverted to CoW (that's why the problem suddenly cropped up again). Hopefully this can help someone else in the future.

Code: [Select]

sudo chattr -R +C /usr/lib/jriver
chattr -R +C ~/.jriver
I don't know which one is the culprit (the system or user directory) but thanks to MC's library backups I'm fine keeping them both disabled. I'm going to add this step to installJRMC if btrfs is detected.

[mwillems]

Aces, glad you got it fixed!