Print

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

[glynor]

Any chance this longstanding issue could be fixed?

Any love on this?

I'm using:
http://localhost:PORT/MCWS/v1/Handheld/Sync?Device=iTunes&DeviceType=Name&ShowWarnings=1

It always responds:


To get it to sync using this command, I have to manually open the item in the Tree and wait for it to process the list.  This makes it essentially useless for automation, obviously.

To make it very plain:
The MCWS /Handheld/Sync command cannot be used as it stands. It works only if you first manually open up MC and navigate to the handheld in question in the tree (so that it preps the sync list). Otherwise you always get a failed response (and if you aren't suppressing the warnings, it tells you the device isn't ready).

So, it needs to either:
1. Have a second /Handheld/RecheckSync command which you can run before you run the Sync command in your script.
2. Just do #1 automatically when you do Sync.

I'm still trying to automate my iTunes sync, as I was when I posted the above many, many moons ago. But, now I'm trying to do another cool little sync trick. I have a Smartlist which auto-generates a shuffled list of 100-odd recent photos from my library which are roughly appropriate for wallpaper images. I want to sync this smartlist to a folder on disk periodically. DisplayFusion uses that folder as one of the sources for its wallpaper slideshow.

If I do it manually with the Wallpaper "device" I made, it works perfectly right now. But, it never updates the sync list, and if MC is ever closed and re-opened (or the sever rebooted), it then fails unless I first manually open the Handhelds section of the tree, and then choose the Wallpaper "device".

Of the two solutions, I'd probably prefer #1 because I'd also still like to automate my Apple iCloud Music sync Handheld, which is what I was trying to do when I made that post above so many, many moons ago. But that one (unlike my little 100-item Wallpaper device) takes a substantial amount of time to recheck the sync (it syncs about 38k items). So, #2 would probably work, but it is going to make MC act super stupid while it runs and it might be prone to error. With the separate command, I could just have it rebuild the sync, wait an hour or two, and then run the actual sync.

I'm not super-picky with either solution option (or some un-thought-of third way) either.

[Matt]

I'll take a look soon.  I would think we could just wait until everything is loaded.

[Matt]

Thanks for the nudge.

Coming next build:
Fixed: Calls to Handheld/Sync before the handheld engine loaded devices would not work properly.

[glynor]

Thank you, sir!

[glynor]

I should open a separate thread on this, but it is little and you're probably going to come back here anyway so I figure I'll ask...

I noticed one other weird little bug when I was setting up my Wallpaper sync device. If you modify the Images Path for a device and make the value an empty string (so that it matches the default Database Path field and syncs to the root of the device) it works correctly. However, if you re-open the Options for this device again in the future, it silently re-assigns the value of the field back to the default "Images\" value. So, if you do this, you have to remember to reset this each time you make any modification to your device or the path gets screwed up.

I did find that if you use a "\" string instead of blank, then it behaves itself, so there is a workaround. But this is non-obvious since none of the other values require or use the "root slash" prefix.

[Matt]

Yup, I saw that we weren't saving empty values.  It made the filename rule impossible to clear between runs.  I'm changing that as well.

[glynor]

👍

[glynor]

So.... I thought I'd let you know. Your change to this worked... Kinda. They still fail the first time I run them after MC relaunches.

But running the command now itself seems to trigger the Handheld Engine to load. So, after running them and letting them fail, if I then run it a second time they succeed. At least with my small Wallpaper sync it works again effectively immediately (within a 30 seconds or so).

With my iTunes sync (which is currently 37886 files), it is still failing the second time.

However, that Sync list takes a VERY long time to load. I have not timed it, but I'd guess 10-15 minutes for the GUI to refresh and load/display the Sync List. (I always click on it and walk away.) I'm not sure what about my particular sync (other than the size of it and the complexity of the Smartlist that drives it) makes it so slow. In any case, I haven't tested it yet but I suspect if I run it, and then wait 10-15 minutes for it to finish loading that it'll eventually work.

So, thanks. Definitely more usable, but still not perfectly "clean". Since it is a RESTful API though, and you can't just make the Method wait until the loading is complete for it to return (and eventually the HTTP request is just going to time out if you try) I'm not sure how much better you can make it.

I also wanted to offer though...

I've assumed that the Sync Engine takes so long to load and refresh just because it is trying to check 37k files and look for them on disk from scratch each time and it is an inherently slow operation. However, I've done a BUNCH recently to try to optimize that. I did this all recently:

* Moved my iTunes "library" (where it is syncing) to a SSD. The SSD is a 512GB Samsung on a SATA 6G bus which gets over 500MB/s sequential reads and writes in tests for 5GB files, so it isn't NVMe or PCIe speed, but it is pretty fast for a SATA SSD.
* Moved my MC Library (the database) over to the same SSD.
* Moved my real media to a new 16TB RAID6 volume on an Areca SAS card, which gets ~380MB/s sequential reads and ~500MB/s sequential writes (and astronomical speeds on small files that fit in the cache).
* Fixed my boot SSD volume which was (apparently) stupidly plugged into a SATA 3G weirdo ASMedia port instead of the 6G Intel onboard port all this time for no good reason and it now matches the performance of the iTunes Media Cache drive. That was stupid.

I expected these changes to make a pretty dramatic difference in the speed of loading the Sync engine in MC. And they did, but it took it from an interminable 20-25 minutes to a slightly less interminable 10-15 min. That and it is slow even on the first sync (maybe even slower) when the iTunes "destination directory" is totally empty. Which makes me wonder if my core assumption that I was just disk limited might be wrong and there might be some other bugs or nonsense in there slowing it down. The speed of the sync itself is much faster now (so that's good) but I'm not worried about that. I'm talking about the time it takes to "Recheck Sync" in MC or open the Handheld for the first time. It takes a LONG time and the whole Handheld part of MC freezes while it is running (and occasionally the whole UI of MC locks up intermittently while it runs).

If you want, I'd be happy to give you a copy of my Library Backup and you could try it yourself. It'd be clunky to set up an I: drive to replicate my sync location, but all the rest of it should work basically the same (except of course the sync itself would fail if you tried to run it because all the source files would be missing).

But if you don't have the optimization itch to do that, I'm not worried about it. I'm just very glad it works now. I can tweak my scripts to run it, check for failure, then if it fails sleep a couple minutes and try again.

[glynor]

PS. Yes. I waited the time it took me to type that post up (probably 15 min but who knows) and then ran my iTunes sync script again and this time it worked.