Jump to content


Photo

The cover file was deleted by emby

metadata cover.jpg

  • Please log in to reply
33 replies to this topic

#1 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 15 May 2019 - 01:33 AM

Emby will modify the video resources downloaded by pt.
For example, this directory:

5cdba2d892625_QQ20190515132530.png

If there are cover. JPG and NFO files under the video directory, there are two problems:
Question 1: NFO files will be modified so that PT resources can not continue to upload. (Even if you set emby without any data to the video directory, obviously there is no option to set the media library read-only mode and use database metadata as the benchmark.)
Solution: Unload NFO plug-ins and install XML plug-ins
Question 2: Checking to replace an existing image when refreshing metadata will result in the deletion of cover.jpg in the video directory´╝Ť
step:
5cdd031c8359a_TIM20190516142809.png
This operation should delete the files under ".../EmbyServer/programdata/metadata/...xxx.jpg" and modify the image path index information of the metadata in the database;
Instead of deleting files directly in the resource directory
 
Solution: No, it's probably a bug.
 
Whether it's Question 1 or Question 2, I want to have the option of setting the media library as read-only, storing metadata or modifying information through the path hash, rather than directly acting on the media library data.
 
In addition, another solution is that before the database metadata of this directory is established, the metadata generated by video is preferentially used. Later metadata-based modifications only operate on the database metadata. In this way, the read-only scheme for metadata of media database is realized, and compatible with other non-metadata-related schemes. Function: Create transcoded video format.
 
#####################
At present, there is no friendly solution to the video media library downloaded by Private Tracker. Please think carefully about the feasibility of another solution I mentioned.
 
Any information modification and image modification of metadata only takes effect in the database, even if one option can be set.
 
I hope that there is an option or scheme to avoid contamination of media library files; even if it is possible to add files, it is absolutely not allowed to modify and delete files.
 
As far as I know, most people who use emby have a huge amount of film resources.
Most of these resources come from Private tracker Site, not BitTorrent;
In order to get more resources, these resources have to be uploaded for a long time. If the resource file is modified, the upload will be terminated, which will make the use of Private tracker and emby conflict.
There is only one kind of compromise solution, that is, don't download video resources with attach nfo files and cover files, but this method is too limited.

Edited by juebanlin, 16 May 2019 - 02:53 AM.


#2 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 46018 posts
  • Local time: 12:34 AM

Posted 15 May 2019 - 11:16 AM

PT?



#3 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 134323 posts
  • Local time: 12:34 AM

Posted 15 May 2019 - 12:07 PM

I would not recommend using the xml files as that is a legacy format now.

#4 GrimReaper76 OFFLINE  

GrimReaper76

    Advanced Member

  • Members
  • 137 posts
  • Local time: 06:34 AM
  • LocationCroatia

Posted 15 May 2019 - 03:45 PM

Emby will modify the video resources downloaded by pt.
For example, this directory:
5cdba2d892625_QQ20190515132530.png
If there are cover. JPG and NFO files under the video directory, there are two problems:
Question 1: NFO files will be modified so that PT resources can not continue to upload. (Even if you set emby without any data to the video directory, obviously there is no option to set the media library read-only mode and use database metadata as the benchmark.)
Solution: Unload NFO plug-ins and install XML plug-ins
Question 2: Checking to replace an existing image when refreshing metadata will result in the deletion of cover.jpg in the video directory´╝Ť
Solution: No, it's probably a bug.

Whether it's Question 1 or Question 2, I want to have the option of setting the media library as read-only, storing metadata or modifying information through the path hash, rather than directly acting on the media library data.

In addition, another solution is that before the database metadata of this directory is established, the metadata generated by video is preferentially used. Later metadata-based modifications only operate on the database metadata. In this way, the read-only scheme for metadata of media database is realized, and compatible with other non-metadata-related schemes. Function: Create transcoded video format.

Truth be told, I can hardly understand what are you trying to achieve?
If you want only database entries, why do you have nfos enabled in Emby in the first place?
If you want nfos, how do you expect any program to selectively distinguish where it originated from? Little bit read/write, little bit read/don't write, little bit no access? It's software, not an A.I.
Or I'm just reading it wrong, I'm trying to wrap my head around it and obviously failing.

Edit:
And what does PT stand for? Private tracker?
Cheers.

Edited by GrimReaper76, 15 May 2019 - 04:11 PM.


#5 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 16 May 2019 - 01:19 AM

I would not recommend using the xml files as that is a legacy format now.

 

 

 

At present, there is no friendly solution to the video media library downloaded by Private Tracker. Please think carefully about the feasibility of another solution I mentioned.
 
Any information modification and image modification of metadata only takes effect in the database, even if one option can be set.
 
I hope that there is an option or scheme to avoid contamination of media library files; even if it is possible to add files, it is absolutely not allowed to modify and delete files.
 
As far as I know, most people who use emby have a huge amount of film resources.
Most of these resources come from Private tracker Site, not BitTorrent;
In order to get more resources, these resources have to be uploaded for a long time. If the resource file is modified, the upload will be terminated, which will make the use of Private tracker and emby conflict.
There is only one kind of compromise solution, that is, don't download video resources with nfo files and cover files, but this method is too limited.

Edited by juebanlin, 16 May 2019 - 02:21 AM.


#6 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 16 May 2019 - 01:39 AM

Truth be told, I can hardly understand what are you trying to achieve?
If you want only database entries, why do you have nfos enabled in Emby in the first place?
If you want nfos, how do you expect any program to selectively distinguish where it originated from? Little bit read/write, little bit read/don't write, little bit no access? It's software, not an A.I.
Or I'm just reading it wrong, I'm trying to wrap my head around it and obviously failing.

Edit:
And what does PT stand for? Private tracker?
Cheers.

1. When the media library is scanned for the first time, metadata information is generated in the database.
2. The operation of modifying the media or replacing the video picture in the middle (the operation on the app does not refer to the operation of the file), and acts on the metadata of the database instead of directly modifying the nfo file and the picture under the directory.
3. The app displays the metadata information required by the media to read the database first. If not, the file directory is read, and then the information in the media file directory is generated into the database, so that the database can be read directly next time.
 
The principle is very similar to the cache, the difference is: this cached data will not be modified downwards.


#7 GrimReaper76 OFFLINE  

GrimReaper76

    Advanced Member

  • Members
  • 137 posts
  • Local time: 06:34 AM
  • LocationCroatia

Posted 16 May 2019 - 01:52 AM


1. When the media library is scanned for the first time, metadata information is generated in the database.
2. The operation of modifying the media or replacing the video picture in the middle (the operation on the app does not refer to the operation of the file), and acts on the metadata of the database instead of directly modifying the nfo file and the picture under the directory.
3. The app displays the metadata information required by the media to read the database first. If not, the file directory is read, and then the information in the media file directory is generated into the database, so that the database can be read directly next time.

The principle is very similar to the cache, the difference is: this cached data will not be modified downwards.


But why then you are insisting in using nfos, all that you said is achieved by default, using database only?

#8 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 16 May 2019 - 01:56 AM

But why then you are insisting in using nfos, all that you said is achieved by default, using database only?

Now has nothing to do with nfo, the problem of nfo has been solved, the problem that scares you is that the cover will be deleted. Whether I use or not, the cover file will be deleted due to refresh metadata.

At first, I found that the NFO file had been modified, so I uninstalled NFO and installed XML plug-ins. This problem was solved.
 
Finally, I found that the "cover. jpg" file will be deleted, which has nothing to do with using or not using NFO files, but emby itself will do so, even if metadata information is in the database, it will still give priority to modifying the information files under the resource directory.

Edited by juebanlin, 16 May 2019 - 02:04 AM.


#9 GrimReaper76 OFFLINE  

GrimReaper76

    Advanced Member

  • Members
  • 137 posts
  • Local time: 06:34 AM
  • LocationCroatia

Posted 16 May 2019 - 02:06 AM

Now has nothing to do with nfo, the problem of nfo has been solved, the problem that scares you is that the cover will be deleted. Whether I use or not, the cover file will be deleted due to refresh metadata.

Well, I'm scared sh*tless. ;)
That makes no sense, your covers should remain unaffected, moreover (as much as I am aware) naming scheme used for Movies/Series is poster.jpg and not cover.jpg. If you're positive that Emby is the culprit and not some other app that has access, guess it's a bug, albeit quite big to be overlooked by now.

Edited by GrimReaper76, 16 May 2019 - 02:18 AM.


#10 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 16 May 2019 - 02:14 AM

Well, I'm scared sh*tless. ;)
That makes no sense, your covers should remain unaffected, moreover (as much as I am aware) as that naming convention is not used, it's poster.jpg and not cover.jpg. So I see no reason why your files would be even recognized as such, let alone deleted?

You can try to download a movie resource with "cover.jpg" in a directory and then join the media library. When you modify the cover image of the movie in the app, you will find that the cover in the file directory is deleted.


  • GrimReaper76 likes this

#11 GrimReaper76 OFFLINE  

GrimReaper76

    Advanced Member

  • Members
  • 137 posts
  • Local time: 06:34 AM
  • LocationCroatia

Posted 16 May 2019 - 02:21 AM

You can try to download a movie resource with "cover.jpg" in a directory and then join the media library. When you modify the cover image of the movie in the app, you will find that the cover in the file directory is deleted.


What do you mean by modify? Choose another one?

#12 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 16 May 2019 - 02:28 AM

What do you mean by modify? Choose another one?

5cdd031c8359a_TIM20190516142809.png

This operation should delete the files under ".../EmbyServer/programdata/metadata/...xxx.jpg" and modify the image path index information of the metadata in the database;
Instead of deleting files directly in the resource directory

Edited by juebanlin, 16 May 2019 - 02:34 AM.


#13 GrimReaper76 OFFLINE  

GrimReaper76

    Advanced Member

  • Members
  • 137 posts
  • Local time: 06:34 AM
  • LocationCroatia

Posted 16 May 2019 - 02:36 AM

You can try to download a movie resource with "cover.jpg" in a directory and then join the media library. When you modify the cover image of the movie in the app, you will find that the cover in the file directory is deleted.


I can confirm recreating same steps, and getting same result: cover.jpg DOES get deleted.
Puzzled.

#14 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 16 May 2019 - 02:41 AM

I can confirm recreating same steps, and getting same result: cover.jpg DOES get deleted.
Puzzled.

Thank you very much, I have raised my questions and opinions, and some possible solutions, but because of my English language ability, I may not be able to express it very well. I hope that my friends who understand my ideas can help me express my thoughts.


Edited by juebanlin, 16 May 2019 - 02:43 AM.


#15 GrimReaper76 OFFLINE  

GrimReaper76

    Advanced Member

  • Members
  • 137 posts
  • Local time: 06:34 AM
  • LocationCroatia

Posted 16 May 2019 - 02:50 AM

Thank you very much, I have raised my questions and opinions, and some possible solutions, but because of my English language ability, I may not be able to express it very well. I hope that my friends who understand my ideas can help me express my thoughts.


Well, for starters, try to keep it shorter, as you did in last few posts. ;) As a non-English native speaker myself, I really did have certain problems trying to comprehend what were you trying to explain, but that ain't entirely your fault.
Anyway, nice catch, I agree that files in folders should not be in any way modified or deleted if not specifically given permission to.
We'll see what the devs say.

Cheers
  • juebanlin likes this

#16 Happy2Play OFFLINE  

Happy2Play

    Trial and Error

  • Moderators
  • 15035 posts
  • Local time: 09:34 PM
  • LocationWashington State

Posted 16 May 2019 - 02:01 PM

You have to remember Local metadata and images take priority over any setting, so they will be read.  You can not have both local and localized image and database metadata.  So yes the Replace all/replace existing will clear you local images/metadata  when you do a refresh operation as your setting are saying you don't what this information with the media.  So Emby clears the information from the media folder as it is considered redundant.



#17 GrimReaper76 OFFLINE  

GrimReaper76

    Advanced Member

  • Members
  • 137 posts
  • Local time: 06:34 AM
  • LocationCroatia

Posted 16 May 2019 - 06:33 PM

You have to remember Local metadata and images take priority over any setting, so they will be read. You can not have both local and localized image and database metadata. So yes the Replace all/replace existing will clear you local images/metadata when you do a refresh operation as your setting are saying you don't what this information with the media. So Emby clears the information from the media folder as it is considered redundant.


Well, I disagree with that behaviour as the original file was NOT created with Emby and it should not be altered in any way as such. If one has nfos enabled, then one does explicitly give permission for files to be created/modified/deleted inside local folder, otherwise internal folder structure should be left untouched and unmodified, regardless of type of files inside.

#18 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 16 May 2019 - 09:38 PM

You have to remember Local metadata and images take priority over any setting, so they will be read.  You can not have both local and localized image and database metadata.  So yes the Replace all/replace existing will clear you local images/metadata  when you do a refresh operation as your setting are saying you don't what this information with the media.  So Emby clears the information from the media folder as it is considered redundant.

I think I can have both local metadata and database metadata.
Think of the database as a cache, the priority is higher than the local, when the database does not have metadata information, generate database metadata based on local metadata, and then always read the metadata of the database first; later edit the movie information Operate at the database level. Similar to the snapshot-based writeback mechanism.
Finally, it's important that you can't tell Private Tracker players that I can modify your media data at will, which is unlikely.

At the same time, if emby can support Private Tracker friendly, such as the naming format recognition of movies downloaded from PT site, I think this is a way that emby can be widely accepted.

I think this is a way to promote emby.
According to my survey, 90% of emby is Private Tracker users.

Edited by juebanlin, 16 May 2019 - 10:21 PM.


#19 Happy2Play OFFLINE  

Happy2Play

    Trial and Error

  • Moderators
  • 15035 posts
  • Local time: 09:34 PM
  • LocationWashington State

Posted 16 May 2019 - 10:11 PM

Every country is different but from a legal standpoint I don't see Emby ever being promoted to be Private Tracker friendly.



#20 juebanlin OFFLINE  

juebanlin

    Advanced Member

  • Members
  • 35 posts
  • Local time: 12:34 PM

Posted 16 May 2019 - 10:21 PM

Every country is different but from a legal standpoint I don't see Emby ever being promoted to be Private Tracker friendly.

You understand it wrong, I mean most users of Private Tracker Site are using emby.







Also tagged with one or more of these keywords: metadata, cover.jpg

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users