INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: JRiver Media Center 34.0.20 for Debian BOOKWORM (amd64, arm64 and armhf)  (Read 378 times)

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14186

This is the first build of MC34 for Linux.  Please post bugs here.  Please start a new thread for anything requiring discussion.  Non-bug posts will be deleted.

Download:
Linux AMD64: https://files.jriver-cdn.com/mediacenter/channels/v34/latest/MediaCenter-34.0.20-amd64.deb
Linux ARM64: https://files.jriver-cdn.com/mediacenter/channels/v34/latest/MediaCenter-34.0.20-arm64.deb
Linux ARMHF: https://files.jriver-cdn.com/mediacenter/channels/v34/latest/MediaCenter-34.0.20-armhf.deb

Available in the latest repo.

34.0.20 (04/28/2025)

1. Fixed: Modern Cards: Grey Edition was showing a strong divider in lists the last few builds (reverted to be like previously).
2. Fixed: APO import was not reading frequencies from some files.
3. Fixed: Skins with round corners could show a minor artifact when in fullscreen Display View or Theater View.
4. NEW: JRVR support for r210 10-bit packed RGB input (for some capture cards).
5. Fixed: Added some missing skin items back to ModernCards Dark.
6. NEW: Support for rendering Theater View in BT.2020 color primaries (Settings -> Theater View -> Advanced).
7. Changed: Upgrading Media Center through the Installer will copy the cached Spotlight data.
8. NEW: Rich Data can be added to files through the file context menu. These are ZIP files that can contain multiple images, PDFs, text files, etc. A new toolbar button (next to Spotlight) is displayed to View Rich Data when it exists for the selection.
9. Changed: Media Center will cache a higher resolution thumbnail for cover art, reducing access to the full resolution image. This will cause the thumbnail cache to be rebuild. Updating both server and client is recommended.
10. Changed: Media Center will force VSYNC to be enabled in the NVIDIA profile to avoid video playback glitches.
11. NEW: VST3 can have the channel selection fully manual to fine tune your speaker profile (Options > Audio > Advanced > VST Channel Selection).
12. NEW: PDF and TXT files are now "played" inside MC in a new browser window.
13. Fixed: The sample count reported in DSF conversion from SACD in the header was not correct.

34.0.19 (4/17/2025)

1. NEW: The Modern Card skins use rounded corners on Windows 11 to match the Windows aesthetic.
2. NEW: Skins can opt into automatic rounded corners on Windows 11 using the <ROUNDCORNERS> element.
3. Changed: Reverse previous View Extras changes.

34.0.18 (4/14/2025)

1. Fixed: There were skinning artifacts in ModernCards Grey and Twilight last build.
2. NEW: Added support for the additional 7.1.4 channels to Room Correction (from the 7.1 it supported currently).
3. Changed: PlatformVersion in Skins can be specified up to the third component (eg. 10.0.22000 for Windows 11).
4. Fixed: The Hilight3DColor from the skin could be incorrect since the supported name change.
5. NEW: Added support for "Preamp" to APO import.
6. Changed: Updated the new / improved this version link for v34.
7. Changed: Added support for a different naming of low shelf and high shelf filters to APO import.
8. NEW: Toolbar button is now shown next to the Spotlight button to indicate the current selection has "Extras" (additional cover art, album booklet, etc.).  Pressing the button shows a temporary playlist with all the Extras files.  "All .." was also added to the View Extras right-click menu to do the same.

34.0.17 (4/10/2025)

1. NEW: Added the playback command "Add (after last add)".
2. Fixed: Tag writing did not work with Heif/Heic images.
3. NEW: Clicking a tree item with ALT pressed will open in a new tab.
4. Changed: Clicking locate links to open a new tab uses the ALT key as well (was control last build).
5. Changed: Updated all stock skins to clean up the XML and images (thanks EnglishTiger).
6. Fixed: Channel Layouts were not being read properly from WAV files.
7. NEW: Support for 7.1.2 channel layout in the audio engine.

34.0.16 (4/8/2025)

1. NEW: Support for HDR 3DLUTs in JRVR - experimental (windows only).
2. Changed: Switched the 10 tab limit for showing the new tab button to 20 tabs.
3. Changed: When resizing tabs, space for the new tab button should remain.
4. NEW: Clicking the locate links next to artists, albums, etc. with control pressed will open a new tab.
5. Changed: Lyrics lookup logs for undo.

34.0.15 (4/3/2025)

1. Changed: When playing decoded files from memory, the memory needed will be allocated in one chunk instead of growing as it reads the file.
2. Fixed: Lyrics lookup could put information about the contributors at the start of the lyrics.
3. NEW: Added a "Dirty" flag to MCWS SetInfo so a file can be changed without flagging as dirty (which moves and tags the file).
4. NEW: Added 5.1.2 configuration as a possible output (JRSS will not fill the height channels today).

34.0.14 (4/1/2025)

1. NEW: Upgraded to Monkey's Audio 11 featuring multi-threaded encoding and decoding.
2. Fixed: When converting a file it could run much slower than necessary.
3. Changed: Skinning looks at Highlight3DColor then Hilight3DColor when checking the splitter.
4. Changed: Skinning looks at HighlightTextColor then HilightTextColor when checking the options list.
5. Changed: Skinning looks at HighlightBackColor then HilightBackColor when checking the options list.
6. Changed: Skinning looks at Highlight3DColor then Hilight3DColor when checking the frame.

34.0.13 (3/26/2025)

1. Changed: For simplicity, removed the option to track deleted files (delete from disk if you don't want tracking).

34.0.12 (3/25/2025)

1. NEW: Added support for APO file import to Parametric Equalizer (APO can be saved by AutoEQ, REW, etc.).
3. Changed: Skinning will load from the values "SelectedBackColor" and "SelectedTextColor" for the OptionsList and fall back to "SelectTextColor" and "SelectBackColor" if those are not found.
4. Changed: Skinning will load list HighlightTextColor and fallback to OverTextColor if that is not found (to name consistent with other areas) for both the tree and list.
5. Fixed: If a file was marked as HDCD that was not it could crash.
6. Changed: When a mounted folder goes away auto-import will not remove the files any longer if it's protecting missing drives.

34.0.11 (3/20/2025)

1. Changed: Updated the Library Server invitation with HTTPS.
2. Changed: Restored the MakeFinalItemSameWidth tag skin rule because it was needed by some skins.

34.0.10 (3/18/2025)

1. Changed: Made the left and right keys without control down seek audio while it's playing.
2. NEW: Added new JRVR profile selection properties for the cropped video image ([JRVR Cropped Width], [JRVR Cropped Height], [JRVR Cropped AR]).
3. Fixed: When using Aspect Ratio Correction in JRVR, the OSD (and other overlays) were pushed away from the image border.
4. Changed: Removed the MakeFinalItemSameWidth tag skin rule because it's hopefully not needed (please report any issues).
5. Changed: Removed the InactiveBlend color from the toolbars section of skinning (was not being used).

34.0.9 (3/14/2025)

1. Changed: HDCD detects files marked as HDCD with no effectual changes.
2. Changed: The MCWS function UserInterface/Show works in Theater View.
3. Fixed: The Playing Now popup would steal the keyboard focus when typing in the search box.

34.0.8 (3/13/2025)

1. Fixed: Processing volume independently of internal volume could result in a pop when reducing the volume to zero.
2. Changed: The audio engine always uses 24-bit for HDCD files.
3. Changed: Switched the tab dragging image to the move icon.
4. Changed: The JRVR OSD shows the input FPS as reported by the source filter.

34.0.7 (3/12/2025)

1. Fixed: Add All in Theater View was not working properly.
2. Changed: Slovak translation updated (thanks Peter Lukáč).
3. Changed: Updated Czech translation (thanks Jan Boháč).
4. Changed: Updated the Catalan language (thanks Josep).
5. Fixed: The Playing Now popup would break Theater View keyboard navigation while it was showing.

34.0.6 (3/11/2025)

1. Fixed: Dragging tabs to change the position was working on a delay like dragging files to the tabs. Changed to be immediate like before.
2. Fixed: https:// URLs were not using live metadata (from Icy or otherwise).
3. NEW: FLAC radio streams will read track metadata from VorbisComment blocks of each track during playback.
4. NEW: Added an option Options > Tree & View > Tree > Remember expansion state on restart.
5. Changed: Revised the file selection logic used by MCWS "Selected" to work better with Theater View.

34.0.5 (3/6/2025)

1. Changed: Revised the Action Window buttons a bit so showing something like a handheld list will also show a close button.
2. Fixed: The new WavPack encoding levels did not work properly.
3. Changed: Update the FLAC input plugin to handle streaming radio streams.
4. Changed: Channel counts above 12 were getting unintentionally handled differently in the last build.

34.0.4 (3/4/2025)

1. Changed: Updated Parametric Equalizer channel selection for the new 7.1.4 layouts.
2. Changed: Minimized Action Windows no longer revert to the home page when restoring.
3. Fixed: Sorting a pane by the grouping expression was not working.
4. Changed: Updated to WavPack 5.8.
5. Changed: Made link expansion a playlist property that gets saved (instead of resetting each launch).

34.0.3 (2/25/2025)

1. Changed: Updated Greek translation (thanks Panagiotis).
2. Changed: Updated German translation file (thanks Bytestar).
3. Changed: Made the program default 3 channel files to L, R, C instead of L, R, SW unless a SW channel is explicitly called for.
4. Changed: Made playback support 3 channel input files (previously they were being rejected).
5. Changed: Updated the search icon in options.

34.0.2 (2/21/2025)

1. NEW: Added a search image to the left of the options search.
2. NEW: When loading a library a wait message is shown to inform you.
3. Fixed: Command line calls that took a BSTR would crash when passing values that were not BSTR values (i.e. /MCC 22043,123).

34.0.1 (2/18/2025)

1. Changed: Made some more options items that showed a menu a droparrow icon instead of a three dots icon.
2. Fixed: Right-clicking an option group then clicking the group name while the menu was showing would incorrectly start an in-place edit.
3. Changed: Media Network options show the same right-click selection as other option pages.
4. NEW: Added the option "Behavior when closing final tab" to specify whether it should ask, close, or do nothing.
5. Changed: Updated all translations to the latest strings from the code.
6. NEW: Added "Selected" as a FileType to MCWS file based calls.
7. Fixed: GPS coordinates are loaded from more images.
8. NEW: Added a SACD to DSF converter (right-click SACD files).
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5312
  • "Linux Merit Badge" Recipient

So I upgraded a client before upgrading my server to test, and the client can't seem to keep a thumbnail cache (i.e. it can build missing thumbnails, but then loses them all on the next restart).  I assume this is expected behavior because the server needs to be upgraded as well? 

If so I'll upgrade the server and forge ahead, I just usually like to kick the tires with new versions on a test system for a few days before moving to production  ;D
Logged

Hendrik

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 11149

So I upgraded a client before upgrading my server to test, and the client can't seem to keep a thumbnail cache (i.e. it can build missing thumbnails, but then loses them all on the next restart).  I assume this is expected behavior because the server needs to be upgraded as well? 

Yes, with a new client and old server thats expected, because the cache is missing the higher resolution version since the server does not provide it. And a missing quality level causes it to rebuild when the thumb database is vacuumed (typically on restart).
I choose this compromise so that clients at least show some thumbs still until both are updated.

Old client and new server should work better, as it'll just ignore the extra thumb.
Logged
~ nevcairiel
~ Author of LAV Filters

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5312
  • "Linux Merit Badge" Recipient

Yes, with a new client and old server thats expected, because the cache is missing the higher resolution version since the server does not provide it. And a missing quality level causes it to rebuild when the thumb database is vacuumed (typically on restart).
I choose this compromise so that clients at least show some thumbs still until both are updated.

Old client and new server should work better, as it'll just ignore the extra thumb.

Thanks for confirming.  I went ahead in the interim and upgraded on the server, but I seem to be missing some cover art that was there before the upgrade (which is unusual)?  I'll keep kicking the tires and see if I can figure out what's causing it. 

Also, it seems like the new thumbnails take up a lot more space than the old ones?  Is that to be expected?  Any sense of how much more space it should take up?  My old thumbs took up about 3GB, and the new ones seem to take up a bit more than three times as much space?


EDIT:
I figured out the missing cover art issue.  The new thumbnails took up quite a lot more space than the old ones which exhausted the space on the partition that I use for JRiver's library.  So I was just seeing some squirrelly behavior because I'd run out of harddrive space because the JRiver library went from 3 GBs of thumbs to 12+ GBs of thumbs.  Expanding the partition/making room on the drive and rebuilding thumbs fixed my missing cover art issue. 

As an aside, it's interesting that JRiver doesn't seem to "notice" when the drive it's writing to runs out of space on Linux?  In my case it just kept trying to build thumbnails (i.e. the "build missing thumbnails" window kept right on counting up) and jriver threw no errors (at least not in the GUI).  I only found out I'd exhausted my harddrive space because the system monitoring daemon on my server started sending me emails  :-[
Logged

warchild

  • Recent member
  • *
  • Posts: 26

I notice that a full library backup is about 25% the size of the 33,71 backups. Is there something important that its ignoring? My audio library is over 30k tracks and about 50 populated playlists (only 6 smart). So what's missing?
Logged

marko

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 9284

thumbnails?
Logged

Some alternative skins are here | Import Stats on Steroids | Middle click the close button=One of the neatest things added to MC in a long time

Awesome Donkey

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 8342
  • The color of Spring!

It's the thumbnails, since they're higher quality now.

For me library backups with thumbnails went from over 400MB to 2.4GB. Personally I'm fine with it, as thumbnails seem to be loading much faster in JRemote3 now.
Logged
I don't work for JRiver... I help keep the forums safe from "male enhancements" and other sources of sketchy pharmaceuticals.

Windows 11 24H2 Update 64-bit + Ubuntu 25.04 Plucky Puffin 64-bit (AMD 7900X CPU/AMD 7800 XT GPU/64GB RAM/2TB M.2 NVMe SSD)
macOS Sequoia 15.4.1 (M4 Mac Mini 16GB RAM/256GB SSD)
Windows 11 24H2 Update 64-bit (Intel N305 Fanless NUC 16GB RAM/500GB M.2 NVMe SSD)
JRiver Media Center 34 (Windows + Mac + Linux) | iFi ZEN DAC 3 | JBL 306P MkII Studio Monitors | Audio-Technica ATH-M50x Headphones

Hendrik

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 11149

Thumbnails increasing in size is of course expected, as we include a new size level thats 4 times as many pixels, so the images are considerably bigger. Although for 3GB before and 12GB after, you sure must have a lot of files. My 20k video files barely get to 500MB in MC33.

As for speed - that was of course a goal. If you notice a difference will depend on the resolution of the requested thumbnail. If it was bigger then the previous thumbnail size, then it would request the original image, which is slower. Hence the choice to offer bigger cached thumbnails for modern higher resolution displays - both on TVs in Theater View and mobile high-res screens.
Logged
~ nevcairiel
~ Author of LAV Filters

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5312
  • "Linux Merit Badge" Recipient

Thumbnails increasing in size is of course expected, as we include a new size level thats 4 times as many pixels, so the images are considerably bigger. Although for 3GB before and 12GB after, you sure must have a lot of files. My 20k video files barely get to 500MB in MC33.

As for speed - that was of course a goal. If you notice a difference will depend on the resolution of the requested thumbnail. If it was bigger then the previous thumbnail size, then it would request the original image, which is slower. Hence the choice to offer bigger cached thumbnails for modern higher resolution displays - both on TVs in Theater View and mobile high-res screens.

The library has about 145K files, about 80k audio, 11k video, and the rest in images.  It was about 3GB worth of thumbnails before and now that I've finished fully rebuilding with MC 34, it's closer to 18GB for the new thumbnails! 

I had never noticed much of a delay previously, but I also tended to have my clients build all the thumbs locally as well, so maybe that mitigated it?  In any case, I've got plenty of storage, I just run my Mediacenter server instance on a virtual machine so I didn't have enough space provisioned to deal with that large of an increase on the system drive.  I should be fine with the new system now that I know.  It sounds like a five or six fold increase isn't unexpected given the size of the new generated thumbnails, so everything seems to be working as intended.

That does give me a curious thought, though.  Most (but not all) of my audio files are part of albums where all the cover art is the same for all tracks (i.e. the 12 tracks on the album all have the exact same image as cover art).  Does Mediacenter build separate thumbnails for every audio file in an album even when all the files share the same art?  If not there might be an opportunity for some significant space savings there and maybe some performance improvements too (as MC could access one thumb instead of 8 or 12).  Obviously there are times when not all tracks on an album share cover art so there'd need to be some detection there (maybe some kind of hash comparison built into the thumbnail building process?), but it seems like a common enough use case that there might be some real space and performance savings there if deduplication isn't currently part of the thumbnailing process.
Logged
Pages: [1]   Go Up