Print

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

[flight16]

I go to options, Theater View, and I remove all items but "Audio" and "Video".  I click ok, close MC, then launch it again.  When I am connected to my local library my change persists.  When I am connected to a remote library, my change vanishes and the default items are displayed again in theater view.

Using the latest version of 20.x on Windows.

Is this expected?  Is it a bug?  Will it be fixed?

[mwillems]

It is expected behavior and it's not quite a bug, it's halfway between a design choice and an unimplemented feature.  

The idea of the library server setup is that not just the media but also the library views (to include theater view) will be rolled out from the server to the clients.  Some aspects of the configuration can be edited on the clients but views of any kind cannot; they have to be edited on the server instance, and then they will dutifully roll out to the clients.

So in one sense it's by design (library server is intended to sync views and keep them in sync).  In another sense it's a limitation of the current model because you can't have different views on different client machines (all clients and the server must share a single view scheme).  I do agree that this is an area where the program could do a better job of letting the user know that they can't do what they're trying to do (i.e. throw an error or grey out the options or something).

Bottom line, at the moment if you want to make changes to library views (to include theater view) in a client-server context, you have to do so on the server.  This is one of a handful of things that have to be done on the server at the moment (cover art changes, and importing files are the other biggies).

[flight16]

That makes it kind of interesting.  The server was actually Mac version 20.  I have been using it from Windows at work, and theater view at home from Windows.  I know Mac doesn't have theater view.  I guess that means I won't be able to actually be able to customize theater view in my situation.  Which saddens me a bit because I don't have any extra copies of Windows lying around and I was trying to make due with the hardware I had available.  It really is working flawlessly besides theater view.

[mwillems]

That makes it kind of interesting.  The server was actually Mac version 20.  I have been using it from Windows at work, and theater view at home from Windows.  I know Mac doesn't have theater view.  I guess that means I won't be able to actually be able to customize theater view in my situation.  Which saddens me a bit because I don't have any extra copies of Windows lying around and I was trying to make due with the hardware I had available.  It really is working flawlessly besides theater view.

You will laugh, but here's a (labor-intensive) workaround that might solve your problem.  I say "might" because I don't have a mac and can't test.  

Step 1) Turn off auto-import on the server
Step 2) Backup your server library (on the mac)
Step 3) Restore the mac's library on a windows PC
Step 4) Make your changes to Theater View
Step 5) Backup the now altered library on the windows PC
Step 6) Restore the library on the Mac
Step 7) Check whether your theater view changes have rolled out to clients
Step 8 ) Re-enable auto-import.

Obviously that's a lot of faffing around, but generally theater view customization isn't something I change every day, so (assuming it works) you might be able to work around it this way for the time being.

[flight16]

Thanks for the work-around.  If that works I will be very happy. : )  I'll try it in the next week when I can find some time.

It would be neat if theater mode settings could at least be exposed on Linux/Mac with a big "there is no theater view for you to see here.  these settings are only reflected when using the library from a Windows client."

[mwillems]

Thanks for the work-around.  If that works I will be very happy. : )  I'll try it in the next week when I can find some time.

It would be neat if theater mode settings could at least be exposed on Linux/Mac with a big "there is no theater view for you to see here.  these settings are only reflected when using the library from a Windows client."

I'll keep my fingers crossed that it will work.  Other areas where functionality isn't present cross-platform don't work at all when Mac or Linux is the server (like TV tuners), but in your case the clients are getting a theater view configuration from somewhere, and it almost has to be the server given the way JRiver's libraries work.  So there's hope that this method might work.

[glynor]

I think it'll work, and in fact, I think you could probably do it more simply:

0. Make a Library Backup on the Mac in case this hoses everything.
1. Share the location of the Library on your Mac so your Windows PC can access it over the network.
2. Make sure MC is completely closed (including Library Server) on the Mac.
3. Mount the location made in #1 as a network drive or open the UNC path on Windows to make sure you can access it.
4. DISABLE AUTO IMPORT on the Windows PC (otherwise the next step may break your entire Library because it could remove all of the files from the Library).
5. Add this as an "alternate" Library on the Windows PC and open it.
6. Make your changes. All of the files in the Library will be broken.
7. Close MC on the Windows PC.
8. Re-open MC on the Mac.
9. Re-open MC on the Windows PC. When it first loads, it'll complain that the Library is Read-Only (because it is still opening it "directly").
10. Switch back to the Network library served by the Mac, and it should work.

You CAN edit the Theater View setup on different computers by directly accessing the Library (via a network share). I do this all the time. I suspect it doesn't matter if the server is a Mac or Windows, that the Library itself is the same, so this should (in theory) work just fine.

[flight16]

Tried glynor's instructions twice but no changes to theater mode in my setup.  Will try a library backup and restore next.

[flight16]

I take that back.  glynor's instructions worked perfectly.

Thank you, mwillems for the original suggestion and glynor for the networked version.  JRiver now does what I want it to do.

I would love to see this be an actual in-app, no-hoops, supported feature.  I understand why it works this way, but as a user I just wish I could use the options on Mac (or Windows) to configure this without an awkward workaround.  It could do nothing but benefit future new users, too.

Thanks for the quick response and help.

[mwillems]

I take that back.  glynor's instructions worked perfectly.

Thank you, mwillems for the original suggestion and glynor for the networked version.  JRiver now does what I want it to do.

I would love to see this be an actual in-app, no-hoops, supported feature.  I understand why it works this way, but as a user I just wish I could use the options on Mac (or Windows) to configure this without an awkward workaround.  It could do nothing but benefit future new users, too.

Thanks for the quick response and help.

I think the cross-platform environment is new enough that the devs haven't decided how to handle these kinds of cases.  From my perspective, this is a symptom of a larger issue.  I think the best solution is to just allow clients to edit views instead of requiring that all view changes be done on the server (maybe with an option to disable client-editing on the server or something). 

As it is it's not only a problem for folks in your position with a cross-platform server setup; it's also a problem for folks with headless servers, or for folks who just want to use a different computer than their server for maintenance tasks.  You can do 90% of the maintenance you need to do from a client, but the remaining 10% requires workarounds like this or remote desktop software that can be a pain for normal users. 

I feel like view editing (along with cover art changes and importing into the library) are similar enough to other client-side changes already supported by the library server system (regular tag changes, library deletions, etc.) that integrating them wouldn't turn the whole system on it's head.  And they would add a lot of value.  But maybe there are problems that the devs see that I don't see?

At minimum, it would be nice if MC would let you know (in program) that view editing and cover art changes aren't supported on the client.  As it is, MC will appear to let you apply the changes, but they silently fail or are discarded on the next restart which can be very confusing.

[flight16]

I think the cross-platform environment is new enough that the devs haven't decided how to handle these kinds of cases.  From my perspective, this is a symptom of a larger issue.  I think the best solution is to just allow clients to edit views instead of requiring that all view changes be done on the server (maybe with an option to disable client-editing on the server or something). 

As it is it's not only a problem for folks in your position with a cross-platform server setup; it's also a problem for folks with headless servers, or for folks who just want to use a different computer than their server for maintenance tasks.  You can do 90% of the maintenance you need to do from a client, but the remaining 10% requires workarounds like this or remote desktop software that can be a pain for normal users. 

I feel like view editing (along with cover art changes and importing into the library) are similar enough to other client-side changes already supported by the library server system (regular tag changes, library deletions, etc.) that integrating them wouldn't turn the whole system on it's head.  And they would add a lot of value.  But maybe there are problems that the devs see that I don't see?

At minimum, it would be nice if MC would let you know (in program) that view editing and cover art changes aren't supported on the client.  As it is, MC will appear to let you apply the changes, but they silently fail or are discarded on the next restart which can be very confusing.

Agree with everything.

[glynor]

I agree that would be very useful, though I'm not sure on exactly how it would be best implemented.

It does bring up a whole host of issues. For example, what happens if two or more copies of MC edit the Library at the same time?  Because of the way client sync works, and must work to get the great performance we get, you aren't ever using the served Library itself, but a cached copy. So, you have to have some way to determine which copy is the "truth" and, unlike tagging changes, you might not always be able to just accept "whatever changed most recently" because the changes aren't "atomic" to the file like tagging changes are.  What if:
* one user in her bedroom edits a smartlist on her laptop
* while someone else on the HTPC changes a one of the Media Views in Theater View from Thumbnails to Lineup View Style
* while you edit a whole set of Media Views in Standard View on the Server to implement some new scheme you've cooked up

And then the clients sync their cached changes on their schedule, and the Server has three wildly different "states" for the Library.  Perhaps with some half-implemented. That could get hairy quick.  The Library is somewhat monolithic and interlocking. It can't, as of now at least, pick and choose. Views can reference Views which reference Smartlists which reference Playlists and on and on. So, one of those three copies must be the "truth" and the others are entirely discarded. So, how do you choose?

Sync is hard when multiple simultaneous writes are possible, even when you are working on the "live" database. When working with cached copies, the problems multiply. Frankly, I'd like to see the ability to edit Playlists on Clients work more reliably first, before we go letting Client machines edit the Library state and start mucking around with any of that.

[glynor]

I'm glad my method worked. I suspected it would, as I do a very similar thing on my own machines at home occasionally (not to edit the Library directly, usually, but to let me do Rename, Move, and Copy Files operations from a Client copy of MC).

It is worth noting that, because MC is so scriptable, almost all of this can be scripted so you could execute it nearly entirely from the client side by just running a VB script or something. The tough part is relaunching MC on the Mac after you stop, which would require some special magic (since you can't call a MCWS command to start MC if it isn't already running).

I've tried, with my own scripts, to end-run this by having the server switch to serving a different, dummy Library instead of closing. That way, it is no longer using the "real" Library, so it doesn't open read-only on the client when you access it directly.  But, it is still running and can still respond to MCWS commands so that you can tell it to switch back when you're done. But so far I haven't found the magic sequence of steps and I've ended up with borked Library state when I've tried. I suspect those problems are because MC caches the writes of the Library. So, when the Server switches Libraries, it doesn't always commit things right away (being busy opening the new Library and getting itself ready). But, you have no way to tell, Client side, when it is done if you aren't actually shutting the server down.

You could probably do it with PowerShell on Windows or SSH on Mac, but then you have to open up those servers, and record login credentials in a script in a plain text file on your hard drive, which might not be desirable (it isn't for me).

[mwillems]

I agree that would be very useful, though I'm not sure on exactly how it would be best implemented.

It does bring up a whole host of issues. For example, what happens if two or more copies of MC edit the Library at the same time?  Because of the way client sync works, and must work to get the great performance we get, you aren't ever using the served Library itself, but a cached copy. So, you have to have some way to determine which copy is the "truth" and, unlike tagging changes, you might not always be able to just accept "whatever changed most recently" because the changes aren't "atomic" to the file like tagging changes are.  What if:
* one user in her bedroom edits a smartlist on her laptop
* while someone else on the HTPC changes a one of the Media Views in Theater View from Thumbnails to Lineup View Style
* while you edit a whole set of Media Views in Standard View on the Server to implement some new scheme you've cooked up

And then the clients sync their cached changes on their schedule, and the Server has three wildly different "states" for the Library.  Perhaps with some half-implemented. That could get hairy quick.  The Library is somewhat monolithic and interlocking. It can't, as of now at least, pick and choose. Views can reference Views which reference Smartlists which reference Playlists and on and on. So, one of those three copies must be the "truth" and the others are entirely discarded. So, how do you choose?

I agree with all of this, but I'd like to point out that MC does this exact sorting and triage right now for tag edits, file deletes, and other forms of database editing that are currently allowed for clients.  Tag edits are only atomic if you write them to the files, but database syncing and triage currently works and somehow arbitrates even if you don't write the tags to the files.  They're just database entries, and I'm not sure why the views should be any different.  The library auto syncs every few seconds, so if you have two different people editing the exact same database entry at the exact same time it's hard, no matter what, but I'm not sure those kinds of collisions are that likely for view editing.

FWIW, other programs that have potential for these kinds of database collisions allow users to decide what to do when the logic can't figure it out (i.e. always prefer changes from x source, choose the latest change, ask me every time, etc.).  Even just being able to have a button on a client that "locks" the database and allows full-scope editing would be better than being unable to make those kinds of changes on clients at all.

And none of that explains why cover art can't be synced or files can't be imported on clients; those really aren't that far from existing functions.

Sync is hard when multiple simultaneous writes are possible, even when you are working on the "live" database. When working with cached copies, the problems multiply. Frankly, I'd like to see the ability to edit Playlists on Clients work more reliably first, before we go letting Client machines edit the Library state and start mucking around with any of that.

I don't really use playlists much, but I agree that needs fixed.  And I agree that bi-directional sync is hard.  We're just really close to 100% already, so these corner cases are always irritating.

[glynor]

And none of that explains why cover art can't be synced or files can't be imported on clients; those really aren't that far from existing functions.

There's no import API in MCWS.  I don't know why. Perhaps because there are issues implementing it due to POST size limits, so you need to build an entire new "file upload" system.

[glynor]

Tag edits are only atomic if you write them to the files, but database syncing and triage currently works and somehow arbitrates even if you don't write the tags to the files.

It still only impacts a single file. So, if it goes wrong, the damage is limited. A Media View, because they're cascading filters, can have far-ranging impacts across the entire system stemming from a single invalid change.

I'm also really, really, really not a fan of any sync system that punts and shows a "sync conflict" dialog where the user has to pick between two possible options. That's difficult to avoid, but they are also nearly impenetrable to non-power-users. That's why Dropbox is so special. It never, ever, ever shows you one of those.

The library auto syncs every few seconds, so if you have two different people editing the exact same database entry at the exact same time it's hard, no matter what, but I'm not sure those kinds of collisions are that likely for view editing.

FWIW, other programs that have potential for these kinds of database collisions allow users to decide what to do when the logic can't figure it out (i.e. always prefer changes from x source, choose the latest change, ask me every time, etc.).

Many other applications that do this kind of thing do not have a caching database system. They use a "live" database (often in the cloud) and maybe cache content. That's fine, if you're only tracking limited sets of assets, but then you end up with dismal performance when searching and filtering hundreds of thousands of assets across multiple fields.

I didn't, and don't, intend to suggest it is impossible. I have no doubt that, if they put their minds to it, the team could figure it out. But, is it more important than other things?  Not sure.  That's also just one example of the kinds of issues it raises. There are also issues just deciding what way it should work. Should all clients see the same Views, for example, or would it be better to have a system where some see them one way, and other see them another? And what about Users?  It opens a whole can of worms, and I suspect a bunch of us won't agree on the answers to a lot of the questions.

Again, not impossible. I'd love to see something here, but I think I'd rather see the stuff we have in this realm work in a more reliable fashion first. That is all.

Even just being able to have a button on a client that "locks" the database and allows full-scope editing would be better than being unable to make those kinds of changes on clients at all.

I think this, more modest target, is a good possibility. Some system to do essentially what I've tried to build with my scripts would be awesome. A way for a client to ask the server for read-write access, temporarily.  That could be pretty solidly implemented.  You do something like:

* Client sends a "give me read/write" command.
* Server forces the client to sync, and tells all other clients to sync.
* Then, once it receives replies (or they time out) it puts itself in read-only mode
* And finally it sends a notification to the requesting client, "ok, you have it, for X amount of time before your token expires."
* The client can automatically extend this time while activity is happening by sending a "re-up" command before the token expiration.

But, to do that, the server would need to know about and track the various clients. That would also be nice, but isn't currently implemented either.