Jump to content

.NET Core Package Test Programme for Synology/XPEnology


solabc16
Go to solution Solved by solabc16,

Recommended Posts

Well, that is interesting :)

I, and many others, have been using VA-API for HW-transcoding and there are few threads on that; one is 

 

https://emby.media/community/index.php?/topic/51051-is-ds718-and-ds918-units-supported-yet-for-hw-transcoding/page-3

 

where James also confirmed it.

 

So, there must be some misunderstanding, but which? :)

 

Just in case it still isn't clear yet: Emby supports VAAPI encoding but not decoding.

So decoding will be done in software and encoding through VAAPI (if selected).

Link to comment
Share on other sites

Everbrave

Just in case it still isn't clear yet: Emby supports VAAPI encoding but not decoding.

So decoding will be done in software and encoding through VAAPI (if selected).

 

 

In fact, the new Transcoding Web-UI made me aware that HW-Decoding and Encoding are made with different methods. The older UI made me think that both are made with the same algorithm or at least it was not clear. Which, on the other hand, calls for a decoding method which suits DS918+ (VA-API).

Link to comment
Share on other sites

We do not have a .NET Core package available for the 'evansport' architecture yet.

Hi @@solabc16

 

Not sure it makes sense to apply for testing on evansport, if it does feel free to add me.

I'm on DS415play as well as on a DS218+

 

Thanks & Regards,

Patje

Link to comment
Share on other sites

I am currently moving away from Kodi to either Plex or Emby (I'm in the process of trying both)

 

Setup : 

Server DS1815+  (avoton, 6Gb RAM) (may move to either DS918+ or DS1618+ depending on findings)

 

Clients (LAN based only) :

- nVidia Shied TV on 4k tv

- AppleTV on FHD tv

- Ipad(s) (2018, mini and pro)

 

Would be interested in trying this beta

 

Regards, jc

Link to comment
Share on other sites

Everbrave

3.6.0.64-beta on DS918+ returns black posters (no image) for the movies added after the server update. I tried to identify the media and restarting the server; in vain.


 


EDIT: the same version for Windows fetches the artwork correctly.


  • Like 1
Link to comment
Share on other sites

3.6.0.64-beta on DS918+ returns black posters (no image) for the movies added after the server update. I tried to identify the media and restarting the server; in vain.

 

EDIT: the same version for Windows fetches the artwork correctly.

 

 

 

How to report a problem:https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/

Thanks.

Link to comment
Share on other sites

solabc16

Hello @@Everbrave

 

There are no platform updates in the latest Emby Server package for .NET Core, so the only changes are those introduced by 3.6.0.64-beta.

 

What version were you running previously?

 

If possible, please can you run the send logs utility: https://github.com/MediaBrowser/Wiki/wiki/Synology-:-How-to-Send-us-Support-Logs

 

Best

- James

Link to comment
Share on other sites

Everbrave

Hello @@Everbrave

 

There are no platform updates in the latest Emby Server package for .NET Core, so the only changes are those introduced by 3.6.0.64-beta.

 

What version were you running previously?

 

If possible, please can you run the send logs utility: https://github.com/MediaBrowser/Wiki/wiki/Synology-:-How-to-Send-us-Support-Logs

 

Best

- James

 

 

@solabc

 

Hi James,

 

Before .64, I ran .58 and it was fine.

 

Log uploaded successfully.

 

Thanks

 

EDIT: .64 is working fine on DS415+

 

EDIT 2: on DS918+, "identify" does not return an artwork either

 

EDIT 3: actually, on DS918+, all metadata is missing, not only the thumb artwork.

Edited by Everbrave
Link to comment
Share on other sites

Everbrave

@solabc

 

Hi James,

 

Before .64, I ran .58 and it was fine.

 

Log uploaded successfully.

 

Thanks

 

EDIT: .64 is working fine on DS415+

 

EDIT 2: on DS918+, "identify" does not return an artwork either

 

EDIT 3: actually, on DS918+, all metadata is missing, not only the thumb artwork.

 

 

Here is what I did to repair this issue:

 

- removed the recently added media from the library

- stopped the server

- restarted the DS918+

- restarted the server

- added the media that I removed before

- initiated a "scan all libraries"; which took quite a long time

 

Still, what happened is quite strange especially that it worked fine on the DS415+; my guess is that the server update messed-up things.

In the future, I will stop the server before I install the update.

Link to comment
Share on other sites

solabc16

Hello @@Everbrave

 

Thanks for the update, stopping the sever will not have been the cause - the update process handles all of that, something else must be going on.

 

Hopefully we'll get a better idea once we've had a chance to dig through the logs.

 

Best

- James

Link to comment
Share on other sites

Everbrave

Hello @@Everbrave

 

Thanks for the update, stopping the sever will not have been the cause - the update process handles all of that, something else must be going on.

 

Hopefully we'll get a better idea once we've had a chance to dig through the logs.

 

Best

- James

 

 

@@solabc16

 

Thanks James; I'm really curious to know the cause; please report back when you had the chance to dig through the log.

BTW: .65 is announced but still not showing up in the package center.

Link to comment
Share on other sites

solabc16

Hi guys,

 

Will it in the future be possible to run it on a Synology 213+ (qoriq)?

 

Hello @Bernie V

 

Unfortunately the 'qoriq' based machines are the only Synology platforms in the lineup we can't support. There is no underlying Mono/NETcore support for the processor architecture and it would be too large a piece of work to take this on ourselves (and likely not worth the effort, given the age of their age).

 

Best

- James

Link to comment
Share on other sites

@solabc

 

Hi James,

 

Before .64, I ran .58 and it was fine.

 

Log uploaded successfully.

 

Thanks

 

EDIT: .64 is working fine on DS415+

 

EDIT 2: on DS918+, "identify" does not return an artwork either

 

EDIT 3: actually, on DS918+, all metadata is missing, not only the thumb artwork.

 

 

 

 

3.6.0.64-beta on DS918+ returns black posters (no image) for the movies added after the server update. I tried to identify the media and restarting the server; in vain.

 

EDIT: the same version for Windows fetches the artwork correctly.

 

 

After pinpointing the same behavior in our beta private message group and being pointed to here by @@solabc16 I'm posting what's happening on my .64 version (synology 1813+):

 

In this next image, I've marked the fact that the server itself is correctly scrapping the item (This Netflix TV Show in this case) BUT it's not providing any artwork whatsoever:

 

ZkM1vGw.jpg

 

In this final print-screen, you can see that despite marking "all languages" renders alot of covers, the server should be default populating the poster with the "en" cover found for this particular item. But it's not.

 

gqOY0Ux.jpg

 

And this is not only happening with "posters". It's happening with everything from banners to backdrops. 

 

"The Nun" movie (first print-screen) on the other hand, had it's artwork automatically added after the correct scrape. Wierd behavior and not consistent with any thing I can pinpoint.

 

Hello @@Everbrave

 

Thanks for the update, stopping the sever will not have been the cause - the update process handles all of that, something else must be going on.

 

Hopefully we'll get a better idea once we've had a chance to dig through the logs.

 

Best

- James

 

Would you like me to also provide the SSH log-script?

 

PS: I've jumped from .58 directly to .64 if I'm not mistaken (and if this is of any use at all).

Edited by djhifi
Link to comment
Share on other sites

Check the metadata and image providers that you've enabled for your TV library.

 

Hey there!

 

Nothing has really changed since I backed up my settings for the last installation of .NET beta on the SSD and never fiddle with them but nevertheless, here it is the full settings for that particular library:

 

l5OThtM.jpg

 

 

Current version .64

Edited by djhifi
Link to comment
Share on other sites

It would appear the answer is right there in front of you in your settings. The server is doing exactly what you've told it to do.

Link to comment
Share on other sites

It would appear the answer is right there in front of you in your settings. The server is doing exactly what you've told it to do.

 

Excuse me but what is that really supposed to mean in this case? If the server was doing what I've (always) selected, it would pouplate the following fields after correctly scrapping any given item with the following:

 

iUoG99k.jpg

 

It is finding "en" related artwork and it is not populating in the library accordingly (as I've also shown in the post above). And it was doing it (pre-.64)

 

Since this is being reported by at least 1 more user (also above), I really don't understand what you're trying to suggest here with that or I'm missing something implied in your sarcasm.

Edited by djhifi
Link to comment
Share on other sites

Let's walk through it. Your expectation is that the English poster should have been downloaded, but it wasn't. Why didn't this happen?

 

Take a look at your screenshot from the manual image downloader. Where does it say the English poster comes from? Then check the series image fetchers you've enabled for that library. Is the source of that English poster enabled?

  • Like 1
Link to comment
Share on other sites

Let's walk through it. Your expectation is that the English poster should have been downloaded, but it wasn't. Why didn't this happen?

 

Take a look at your screenshot from the manual image downloader. Where does it say the English poster comes from? Then check the series image fetchers you've enabled for that library. Is the source of that English poster enabled?

 

No, it wasn't indeed, you're right. You're actually helpful when you want to. No need to treat people with sarcasm (being them donators or not) in my opinion. We're all here to try and help each other I'd guess...

 

So I've provided a bad example, my bad, because this is a recent (just added) item. But this behavior (reported by @Everbrave) was def. happening last night with several items.

 

Thanks for pointing that I forgot to tick that particular box.

Edited by djhifi
Link to comment
Share on other sites

Historically we have allowed to use all image providers with the manual image downloader, even when that provider is disabled. I don't think we will be able to do that anymore because this type of thing comes up enough that it causes some to think that something is wrong when it wasn't automatically downloaded.

Link to comment
Share on other sites

mutu310

I'd like to test my DS213j (CPU Model: Marvell Armada 370 88F6707, Package Arch: Armada370) when you're ready. To be honest I'd like to criticize your approach of starting with the more modern architectures; these are the machines on which the performance impact will be lowest. Unless, of course, this is a popularity contest of sorts. In any case, Emby is completely killing my underpowered machine and running TERRIBLY slow (interface is largely unusable, needing occasionaly restarts which take approximately 5 minutes, but switching from one page to the next takes around 30 seconds on average)... I can really evaluate how big an impact .NET Core does on performance, because I figure it will be extreme.

Link to comment
Share on other sites

solabc16

Hello @@mutu310

 

Thanks for your comments. I can understand your viewpoint, however I had to make a decision as to how best to prioritise and make use of the resources at our disposal.

 

You are correct in that there are more active Intel based Synology systems in the field and this of course has a bearing, although not for the reasons your suppose.

 

It's all about getting 'mileage' on the system, and to do this we need a good sized pool of users to make sure we get good coverage of both core functionality and scenario specific use cases.

 

The Mono and .NET Core releases of Emby Server share the same code base, so we're not testing Emby Server per se, but all of the plumbing and support that goes around it.

 

I've written previously about setting expectations, as there is nothing .NET Core that's guaranteed to give us instant order of magnitude performance improvements; and in the interim the Mono project has further incorporated Microsoft source code from .NET Framework and .NET Core. (https://emby.media/community/index.php?/topic/51013-net-core-stable-release/?p=490183)

 

Work on taking advantage of newer libraries, such as Skia, give us tangible performance improvements that sit entirely outside of the runtime component of Emby Server: https://emby.media/community/index.php?/topic/52160-improved-image-processing-performance/.

 

The Armada 370 88F6707 SoC was released on 2013-03-21, so in this context it's an 'old' processor with performance commensurate with its age (for this type of processor). Whilst it does have floating point support, it doesn't support NEON, which also limits it's overall performance.

 

We will look at this processor and it's viability as soon as we are satisfied we have a viable .NET Core package that is suitable for general release and widespread adoption. In the meantime, please feel free to send across your logs using the 'send logs' utility and I'll take a look at your system.

 

Best

- James

Edited by solabc16
  • Like 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...