Honor newline/carriage returns in Overviews on clients

[TrackZ 16]

The meta data pages let you separate text in the Overview with carriage returns; however, on the clients, the Overview text is pushed together into one continuous line/paragraph.

[speechles 1917]

Do you mean \r? Or \r\n? Or just a bare \n? Usually a newline is respected. A carriage return may not be in most software.

 

Sent from my Nexus 7 using Tapatalk

Edited September 5, 2014 by speechles

[TrackZ 16]

I'm not sure on the actual coded representation. Whatever MB logs in the Server when you use the Enter key on your keyboard when editing the Overview.

 

I did find that MBT and the iPad app display the carriage returns. The web client though did not.

[rbjtech 4260]

Has anybody found a solution to this problem ?

I can't get the 'overview' metadata field to recognise any form of newline.

I'd like to use this as part of my crossover episode script (which auto generates the nfo) to list the episodes in the crossovers - but currently it's not recognising html tags, css or any \n?

So as an example below - I've used an asterisk to separate for the moment, but ideally I'd like to have each member of the crossover on a new line... 

[Guest]

Seems like you would need to create another set of tags within the NFO.. with the second one.

[PenkethBoy 2063]

only for a browser via css - needs a hard return in the text

/*---- Item Detail - Overview line break----*/
 div.overview-side-text  {white-space: pre-wrap;}

there was talk of getting html tags recognised by Android etc but that appears to have died off - too difficult apparently

[GreatFlashMan 75]

Thanks for pointing me to this @ebrI searched and my computer does not go all the way back to 2014???????????????????

 

Seriously, I did not find this and made a mention here,

How the ACTUAL **** can this STILL be an outstanding issue after 9 bloody years? It's a fairly easy piece of formatting code for heavens sake, not something "too difficult" as mentioned above. It this is an issue that is "Too Difficult to fix", then I am mightily surprised that Emby has managed to progress this far.

[ebr 14912]

All Emby apps should recognize html line breaks (<br/>) at this time.

[rbjtech 4260]

On 09/08/2023 at 18:59, ebr said:

All Emby apps should recognize html line breaks (<br/>) at this time.

Yep - this has been working for some time ..

Very useful when creating collections ..

Works nicely on Android and AndroidTV - not tested on other clients.

[GreatFlashMan 75]

On 09/08/2023 at 18:59, ebr said:

All Emby apps should recognize html line breaks (<br/>) at this time.

That's not exactly what i mean. The scrape of data that is stored in the nfo file omits these, leaving just a standard carriage return. if html tags are supported, then perhaps the scrape from TVDB etc. should replace them if they are not resepected.

Manually editing 1000's of overview (and other) texts in any form is both a long winded and unwarranted exercise when the software could do this at point of creation.

[rbjtech 4260]

44 minutes ago, GreatFlashMan said:

That's not exactly what i mean. The scrape of data that is stored in the nfo file omits these, leaving just a standard carriage return. if html tags are supported, then perhaps the scrape from TVDB etc. should replace them if they are not resepected.

Manually editing 1000's of overview (and other) texts in any form is both a long winded and unwarranted exercise when the software could do this at point of creation.

Do you have an example of a title that has a CR in it's metadata.  I've only ever wanted it for bespoke collections and specials etc.  'Finding' a CR in a block of text is easy enough, and then replace with <br/> in the emby data and/or nfo is pretty easy to do ..

[GreatFlashMan 75]

are you saying there is no line breaks at source?

I manually added a newline at the start of this, though not the second one. Checking TVDB it is shown all in a block, but no idea if that's the website backend, or the original text?

tvshow.nfo

if it is all stripped, this appears silly and it would be wonderful to have nicely organised text.

[rbjtech 4260]

45 minutes ago, GreatFlashMan said:

are you saying there is no line breaks at source?

Possibly - that's why I'm asking - emby can't do much if the source metadata doesn't contain line breaks

the web browser (I've yet to check the clients) actually honours a fair bit of html formatting .. 

edit - Android Standard App & Emby Theatre does  but AndroidTV does not ..  ... @ebr

<strong>bold</strong>
<h1>Headline 1</h1>
<h2>Headline 2...</h2>
<h6>..Headline 6</h6>
<em>Italics</em>
<hr> horizonal line
<p> new paragraph </p>
Normal text
<br>
Normal &nbsp Text (with Tab)

Edited August 12, 2023 by rbjtech

[rbjtech 4260]

This may actually introduce a new way of getting Album Media Info into the Music screens in emby - as they are sorely lacking in that area ..

This is Android (looks ok, it seems to ignore Bold but that might be the screen grab from the Shield) .. the 'overview' is now used to display that data ..

Browser looks ok .. 

AndroidTV is a bit of a mess though (but I much prefer the look of it generally .. note how much info is missing from the Android above - album length, track length.. )  - but to be fair, I don't play music from my TV devices, it's browser or mobile (Android).

 

I may add into the MediaInfo plugin - to scrape the Album Folder name which contains these details ...

 

 

Edited August 12, 2023 by rbjtech

[ebr 14912]

4 hours ago, rbjtech said:

Android Standard App & Emby Theatre does  but AndroidTV does not .. 

That's because those other apps UI is actually rendered in html but TV is not. 

[ebr 14912]

5 hours ago, GreatFlashMan said:

are you saying there is no line breaks at source?

In most cases I imagine that is correct. It wouldn't make sense to have hard line breaks when you don't know what container it will be shown in. 

[GreatFlashMan 75]

TVShows meta don't appear to have returns in them as a rule (but would be wonderful if honoured if they did)

But music artists do, and like this example, it would really enhance the view in Emby.

rather than presented as this,

 

 

 

[rbjtech 4260]

So looking at the API - emby is storing the New Line in the 'Overview' as a \n

ie in Overview -  (scroll right)

{
  "Items": [
    {
      "Name": "Tape 1, Side A",
      "ServerId": "5f9c466f4ecc4319b1d48f55e311d249",
      "Id": "3091060",
      "Overview": "As the school mourns the death of Hannah Baker, her friend Clay receives a box of tapes with messages she recorded before she committed suicide. \nTest New Line.\n\nTest New Line with Space.",
      "RunTimeTicks": 31776630000,
      "IndexNumber": 1...................................

It looks correct in the metadata editor .. 

 but these are being ignored in the clients.

We know </br> works (HTML formatting) - so why not just interpret \n as a </br> and things will start to look much better ?

It is simple enough to just replace a \n with a </br> in the actual emby 'overview' entry itself - but probably better to do it at the client level.

Remember that the overview only has 3-5 lines visable anyway - but on Android, Web and possibly other clients, you can click on it to get a full expansion.  For Bio's and Music - I agree it looks so much better with proper line breaks and paragraph spacing ...

Edited August 18, 2023 by rbjtech

[rbjtech 4260]

I've just added this into the MediaInfo Plugin .. haha.

It's so small it's not worth it's own code - so I've got it to just replace the item overview with the HTML formatting style.

If you reprocess all the items in MediaInfo Plugin - then it will replace them all automatically - and as new entries as the Plugin processes them ..

(Probably quicker than waiting for all the clients to be updated to acknowledge \n - if that even gets agreed ...)

I'll post an update in the MediaInfo Plugin thread shortly ... but it's working well for me.. 

Edited August 18, 2023 by rbjtech

[rbjtech 4260]

Added this into the latest MediaInfo Plugin for Emby ..

Link below -

https://emby.media/community/index.php?/topic/108984-mediainfo-for-emby-pluginhdr-vision-atmos-dtsx/&do=findComment&comment=1273676

[ebr 14912]

2 hours ago, rbjtech said:

 but these are being ignored in the clients.

Android TV should already respect '\n'.  In fact, that is what it converts the html breaks to since it isn't rendering html...

[rbjtech 4260]

11 minutes ago, ebr said:

Android TV should already respect '\n'.  In fact, that is what it converts the html breaks to since it isn't rendering html...

FireTV appears to respect the HTML line break ? - I believe only the shield shows the </br> instead of acting on it.

Ideally, the clients should do this - but it was just a quick code change in the MediaInfo Plugin to add it - as it's always bothered me as well ... 

edit - ah, correction - so both FireTV and AndroidTV are fine with </br> - it displays nicely in all clients now.

Edited August 18, 2023 by rbjtech

[ebr 14912]

2 minutes ago, rbjtech said:

FireTV appears to respect the HTML line break ?

Yes, because it converts it to '\n'...  Therefore, converting '\n' to the html code is just causing more conversion in that particular app - but necessary for uniformity with the others.  My point was, if your source already contains '\n' new lines, then the TV app should already be respecting those.

 

[rbjtech 4260]

3 minutes ago, ebr said:

Yes, because it converts it to '\n'...  Therefore, converting '\n' to the html code is just causing more conversion in that particular app - but necessary for uniformity with the others.  My point was, if your source already contains '\n' new lines, then the TV app should already be respecting those.

 

Yes - and ideally we would want to keep them as \n - but all the other clients ignore it.   If all clients worked with \n (and converted to </br> as required) - then there would be no need to edit the emby overview source.     

Low priority in the grand scheme of things, but maybe something to add to the next round of client updates if it's quick and easy ..