Syncing covers not working properly

Movies Movie Collector
21

Hm, I’ve just looked up

barcode: 8717662595172 (the MR-9 movie)
title Ring of Dreams (2019)

These both have no “media cover” or even a “movie cover” - they only have a movie poster!

Let me explain.

In Core we have movie level (has a CLZ MovieID). This level can contain a

  • default movie cover
  • movie poster

We also have a media level (has a CLZ MediaID). This level can contain a

  • front cover
  • back cover

On Windows you have the following fields per each entry:

  • Front cover
  • Back cover
  • Movie poster
  • Backdrop

On Web and Mobile you have the following fields that a user can edit per each entry:

  • Front cover
  • Back cover

On top of that, you do get a backdrop on mobile but you can’t edit it.

If a movie in Core has no front cover (either on the media level, or on the “default” movie level) but it DOES have a movie poster in Core on movie level, then mobile will download the poster as a “front cover”. It will however not mark it as custom.

When syncing, it sends up the movie to your Cloud, and checks if a “front cover” is available in Core for it. There is no “front cover” (there is only poster) so it will automatically assume that your cover on mobile is one that you added, and it will “upload it”. Now, Cloud will have a tag saying “custom cover”.

Now on Windows when you downsync, this movie will download with Custom Cover: YES.
If you make any changes now on Windows, this “custom: yes” will sync back up to Cloud, and to phone.

This is a route I had not anticipated, so we’re on the right track.

The other way around then:
If you add such a movie on Windows (no movie/media level cover, but it has a poster), it will download the poster into the “poster field” - however, when you upsync it this works, it stays not custom - this is because Windows “knows” this is a poster. When syncing to mobile, it all seems fine, the cover is still marked as “not custom”. - but: if you EDIT the movie in mobile, it is going to sync up, and the same as above will happen (it decides there is no front cover on Core, but the client is trying to upload something from the “front cover field”, so your cover MUST be custom, and boom, same problem.

It’s too smart that it becomes dumb!

I think I can make a couple of bug reports out of this:

  • Browse/Cancel on Windows (but I’m pretty sure we won’t fix such an old Windows bug anymore… sorry about that)
  • Custom cover “OFF” should sync (but this might be difficult plus usually it would be unwanted, because, once you add your own cover, you’d probably like it to Stay custom anyway.)

But the most important one would be the poster downloading as front cover, and then syncing and the whole thing thinking “it is custom”. I think that is a good one for us to fix, as it would save a lot of space for us too in Cloud :slight_smile:
So I’m at least putting that on our bug list!

Shutting down for the weekend now!

22

I am very happy to hear you figured out the problem based on my analysis and examples.

1st bullet is not a big deal. No problem if it won’t be fixed.
2nd bullet: If you choose it to be a custom cover it will stay custom. That is fine, but if you remove the flag intentionally I think it is desired to sync the off state. There is a reason you remove the custom flag. Maybe I can extend it with a feature request: make it possible in the Web version to change this field also from true to false (I guess it is not possible now, but don’t know because I don’t use the Web version). I guess that is easier to do than syncing it from mobile / desktop.

Indeed it would save cloud storage :slight_smile: . Less custom covers means less store required.

23

Like I said, I am going through my collections to update covers. In most cases it is easy: Update from Core and done. ± 50% of my collection could be updated this way to get a better of more proper version of the cover.

Because of the bugs we found together I cannot get the right cover because it is currently in Custom Cover mode with a wrong cover. From a user perspective the most logica way to solve is:

  • Clear cover (so cover is deleted AND custom cover is disabled). Or just untick custom cover.
  • Update from Core to get the right cover.

I had dozens of examples (just starting) where it was not possible to do (we found the bugs). So only thing I could do is download the cover from Core and upload it as Custom. Really annoying to do.

My point: From actual usage I want able to remove the Custom flag. So it is not a theoretical way of working, but from my actual use cases.

Just for some extra context.

24

Indeed. Annoying, but it works, and you only have to do it once (the upload goes through the sync automatically anyway).

I’m sorry but I just do not have an alternative solution. Because of the bug, it will just keep happening as long as, for instance, we still have just a poster and no default front cover (because mobile, well, I don’t have to repeat the bug we found).

25

Sorry, 1 new finding. I don’t think I will find more stuff.

Alwin gave me a hint today:

So I didn’t know what is exactly meant so I did 1 test with a strange result.
The result is: An entry on Desktop that was marked as Custom is not custom anymore, but also no cover in Web. Again I have a reproduction path:

  1. Web: choose a movie which has a custom cover. Check if Mobile or Desktop the entry is also marked with a custom cover. My example:
    afbeelding
    afbeelding1920×839 141 KB
  2. Web: Remove the Front cover and save.
  3. Now sync Mobile and Desktop with Cloud. Result is the Custom Cover true, switched to false on mobile and Desktop. So syncing true → false works when the initiator is Web. But the cover is also removed on Web. Which makes sort of sense because I removed the cover.
    afbeelding
    afbeelding1920×808 117 KB
  4. On Web it is not possible to switch to the Cover from Core. In the Update from Core screen the Covers are missing. If I would only use Web, I am stuck. No way to “correct” the issue if the right cover is not available with the Find Online feature.
  5. When I enter a new entry in Web and immediatly remove the cover. Then sync Desktop / Mobile with cloud. The new entry is loaded on Desktop/Mobile with the default Cover from Core. So it works fine on those 2 apps.

So Desktop and Mobile think it is not Custom (Web triggered the change). But Web is not showing anything.

Only way to get back a cover is to use Find Online/Upload cover in Web, or make it custom again from Mobile/Desktop.

Now I have the feeling I checked all apps and given you all reproduction paths I could find in this whole mystery.

26

You can click “Restore” above the cover to get the cover from Core if there is a cover on Core.

27

Thanx, totally missed that one. It is I guess the only feature that is different from all the other stuff where to use Update from Core to correct stuff.

This means I know have an option to remove all unnecessary Custom Cover flags. Thanx @CLZ_Alwin and @CLZ_AJ for the hint.

28

But WHY do you want to remove the custom flag? What does it matter to you specifically?

If the cover is good for you, then the cover is good for you. End of story right?
(although I don’t think it will ever be end of story on this one).

29

Short version: I approach the Cover the same way as any other field. There is also no setting for example Custom Genres true/false. It is just Genres. With update from core I replace it or not. For me it works best if covers also work the same way.

When there is incorrectly a custom cover set the easiest way to fix it is by removing it from Web (learned today). The correct one is often not easy available. Much faster than searching and loading the correct one. Core already has the correct one. I don’t have control over you backlog, so I have to work with how it currently works (including the bugs).

I try to make it as easy as possible and use what Core offers. Only technical details and movie titles I manage myself. All other information is coming from Core. I don’t want to think about it too much.

Because I now rely on the covers from core (in the past I didn’t care at all), everywhere where Custom cover checkbox is set, I am spending more time to get the correct one from core. Because when it is set to true it won’t be replaced. Then I have to do multiple steps to fix it. So if I can remove it everywhere where it is in my way I am happy. I only applying it where it has to be custom. For me the whole custom cover flag feels unnecessary.

If it makes sense :slight_smile:

30

Really? Completely unnecessary at all?

If you have a different cover than us that you prefer, you’ve set it, the custom flag switches on, and all is good. And it will never change again and you have your good cover. Forever on Web and Mobile.

You have found a bug where the custom flag gets switched on unneeded, which I’ve recognized and put on our bug list. All good.

But the fact remains that for you, personally, your collection, your covers, if you are happy with the cover you have right there, right then, then that’s it right?

There is no need to worry about what is in Core or if it should or should not update?

Let’s call it a day on this topic, we have our bugs found and reported, and you have your way of unsetting the custom flag now, you’re happy, I’m tired, let’s stop.

31

LOL :joy: Some folks never happy…

32

I was already very excited when I understood what all was happening and it was reproducible by AJ. :slight_smile:

I think Alwin made my mind go that way :worried::

If changes will be made (if it gets priority at all), I am happy to test it for you.

When strange things will wappen I now now exactly how it all works. So @roybo, I am already happy with the results, even nothing has been changed :smiley:.