sslovan 1 Posted January 4, 2021 Author Share Posted January 4, 2021 (edited) Yes, nfo files in my folders. It seems that when Emby refreshes the database after adding subtitles or a replacement video file (identical file name), it reads nfo files by omitting the <br/> code tags. TinyMediaManager also does this, but respects the OS line break command paragraphs. Anyway, I definitely gave up on adding manually <br> tags to my item overviews. It means too much work with a huge film library, and since such tags are not invisible, but are displayed as code text junk in other apps like Emby AppleTV or Infuse, it makes little sense. It is somewhat frustrating that such basics like displaying ordinary text paragraphs (no formatting, just plain line breaks) are still such a complicated affair in 2021.... It reminds me of the 1980s MS/DOS nightmares (I am old enough to remember)..... Edited January 4, 2021 by sslovan Link to comment Share on other sites More sharing options...
Luke 37064 Posted January 4, 2021 Share Posted January 4, 2021 Have you enabled saving metadata to nfo files in emby library setup? Link to comment Share on other sites More sharing options...
sslovan 1 Posted January 5, 2021 Author Share Posted January 5, 2021 Yes... Link to comment Share on other sites More sharing options...
sslovan 1 Posted January 5, 2021 Author Share Posted January 5, 2021 (edited) I make one last effort. I don't want to take up your time with this detail, but please help me to understand, perhaps I am too dumb. 1) I fully understand that Emby server (and .nfo files) keep metadata plain neutral, as different OS have diverging line break code (\r, \n, \r\n) and you need to address many different client apps. 2) Let's say I copy and paste text with paragraphs (line breaks) from a webpage or text editor (in my case on a Mac) into the Emby overview metadata editor, it will reproduce the same text with paragraphs (line breaks). I then do NOT add manual code tags and I just save overview. Emby WebApp will not show text with paragraphs (line breaks) but just the plain text bulk (earlier CSS solutions had been removed for reasons of Javascript security, as far as I understood). Ok, all fine. 3) However, on the Emby AppleTV app, my overview metadata will be rendered as in my original input, with all paragraphs (line breaks), as intended. Wonderful! So the Emby AppleTV app can render line break code in a correct way, without altering metadata on the server! As I mentioned, other apps (Infuse, MrMc, TinyMediaManager) will also interpret line break code from my Emby written .nfo files via Emby server in a correct way. 4) Is the same procedure impossible to add to Emby iOS and Emby McOS apps (NOT WebApp)? As far as my limited understanding goes, this would not touch metadata on the server / .nfo files, thus not affect other line break code interpretations on e.g. Emby Android, Windows, Roku or whatever apps? Would this necessitate too much of reprogramming? Is this completely out of question? I am not complaining, I just would like to understand where the problem lies. The code tag solution (manually added <br>) is too clumsy and time-absorbing once you have to deal with thousands of item entries. In any case, Emby is such a fanatastic media solution, not least because it gives the user the possiblity to build a real interlinked media library, not only to play files, but also to add information, bios, reviews etc. This is so great! So kudos to the whole Emby developer team! Edited January 5, 2021 by sslovan Link to comment Share on other sites More sharing options...
Luke 37064 Posted January 5, 2021 Share Posted January 5, 2021 Is just the different renderers on your devices handling it differently. The br line break tag is the only method we're committed to supporting though. Link to comment Share on other sites More sharing options...
sslovan 1 Posted January 5, 2021 Author Share Posted January 5, 2021 Ok, thanks. Link to comment Share on other sites More sharing options...
Luke 37064 Posted January 7, 2021 Share Posted January 7, 2021 The solution here is to look at why you're losing your customizations after doing things like refreshing metadata or downloading subtitles when locking the overview field. @cayars can you test this out? Thanks. Link to comment Share on other sites More sharing options...
sslovan 1 Posted January 7, 2021 Author Share Posted January 7, 2021 Well, I am going to try once more by adding gradually manual <br> code tags to the overviews of my several 1000s of items. A handy search/replace function for multiple entries in the metadata manager would be a nice dream wish -;) Link to comment Share on other sites More sharing options...
Carlo 4330 Posted January 7, 2021 Share Posted January 7, 2021 12 hours ago, Luke said: The solution here is to look at why you're losing your customizations after doing things like refreshing metadata or downloading subtitles when locking the overview field. @cayars can you test this out? Thanks. I can not. Tried this on a few files. Here is an example: I edited the metadata and added the <br/> tag to get a new line feed. I mocked up in yellow where I added this. I then locked the record then I downloaded an SRT subtitle which I didn't have before. My description stayed as I left it. My NFO also still has the tag in the plot field. <plot><![CDATA[For Lieutenant Pete 'Maverick' Mitchell and his friend and co-pilot Nick 'Goose' Bradshaw, being accepted into an elite training school for fighter pilots is a dream come true. <br/>But a tragedy, as well as personal demons, will threaten Pete's dreams of becoming an ace pilot.]]></plot> So things are working properly for me on 4.6.0.10. Link to comment Share on other sites More sharing options...
speechles 1917 Posted January 7, 2021 Share Posted January 7, 2021 Try with just <br> rather than the self-closing <br/> or <br />. The self-closing tags are meant for XHTML. 1 Link to comment Share on other sites More sharing options...
Carlo 4330 Posted January 7, 2021 Share Posted January 7, 2021 @Luke Is there a preference of using <BR> vs <BR/> tags for line breaks? Is one going to have better support in apps? Nice catch @speechles Link to comment Share on other sites More sharing options...
speechles 1917 Posted January 7, 2021 Share Posted January 7, 2021 (edited) the <br> is the element (not an entity there is no entity for carriage return) for html. The reason to encapsulate it into a self-closing tag is so the parser for the XML can consume it without error. If it were within CDATA it would not need self closing as the CDATA is to encapsulate HTML inside XML. Edited January 7, 2021 by speechles 1 Link to comment Share on other sites More sharing options...
sslovan 1 Posted January 7, 2021 Author Share Posted January 7, 2021 With these <br> tags, it looks like this. Link to comment Share on other sites More sharing options...
sslovan 1 Posted January 7, 2021 Author Share Posted January 7, 2021 A possible reason for the stripping of the <br> code: Until recently, I had automatic "Download subititles" in "Library" ON. The tags would never disappear at once after a manual subtitle download, but only after a certain interval (like overnight). This would also cause dozens of the same subtitles to load in cases where I had a .mkv placeholder (mostly an image file) for my Bluray discs, which were not uploaded to the Emby server. Now, I stopped scheduled subtitles download, only add them manually, and began to add <br> again in overviews. So far the tags remain in place. Link to comment Share on other sites More sharing options...
Luke 37064 Posted January 7, 2021 Share Posted January 7, 2021 Quote The tags would never disappear at once after a manual subtitle download, but only after a certain interval (like overnight). In Emby there's no difference between these two actions, so that leads me to believe that some external program may have updated the nfo file and not Emby. Link to comment Share on other sites More sharing options...
Luke 37064 Posted September 29, 2021 Share Posted September 29, 2021 Emby for macOS 2.0.9 has been released to the macOS app store. Enjoy. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now