Jump to content


Photo

QNAP TS-531P and emby-server-qnap_3.6.0.76_arm-x41.qpkg


  • Please log in to reply
31 replies to this topic

#21 heath600 OFFLINE  

heath600

    Member

  • Members
  • 20 posts
  • Local time: 08:50 AM

Posted 08 April 2019 - 03:45 PM

Seems the same as before running the Emby executable.  ffmpeg seems fully functional now.



#22 heath600 OFFLINE  

heath600

    Member

  • Members
  • 20 posts
  • Local time: 08:50 AM

Posted 18 April 2019 - 08:44 PM

Well the email chain with QNAP support yielded nothing of value.  (I can see why working with them takes forever.  They takes days to respond to emails)

 

On that note I did figure out the kernel was compiled with VPU support on my NAS..  Im surprised QNAP left the config file on there to be honest

CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

So in theory my NAS should have no issue using hardware floating point.



#23 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 134339 posts
  • Local time: 08:50 AM

Posted 19 April 2019 - 02:25 PM

@heath600 yes but I believe I recall we found a case of a QNAP device reporting that it supports it when it actually doesn't. I'm pretty sure it's somewhere in this big long thread:

https://emby.media/c...ge-for-testing/



#24 heath600 OFFLINE  

heath600

    Member

  • Members
  • 20 posts
  • Local time: 08:50 AM

Posted 22 April 2019 - 08:27 PM

Not sure if this helps but I was able to compile a simple program to test hardware float and it seems to work

 

https://github.com/j...b/master/test.c

 

Compiled using the following command

/usr/bin/arm-linux-gnueabihf-gcc test.c -mfloat-abi=hard -O9 -std=c99 -march=armv7-a -mfpu=neon -o test2

and this appears to work fine

 
[~] # ./test2 2.200002 2.200001 5
ans = 9.705820 34741 loop/msec 

On a weird note using any of the soft options does not return a valid answer. (After further testing appear atof is not converting the string properly when using any soft float option.  If I hard-code the variables in the code it works fine)

/usr/bin/arm-linux-gnueabi-gcc test.c -mfloat-abi=soft -O9 -std=c99 -march=armv7-a -mfpu=vfpv3-d16 -o test4


[~] # ./test4 2.200002 2.200001 5
ans = 1.000000 5049 loop/msec

Edited by heath600, 22 April 2019 - 09:01 PM.


#25 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 134339 posts
  • Local time: 08:50 AM

Posted 22 April 2019 - 09:44 PM

Interesting, thanks for the info.

#26 heath600 OFFLINE  

heath600

    Member

  • Members
  • 20 posts
  • Local time: 08:50 AM

Posted 09 May 2019 - 12:08 AM

The latest email I have received by QNAP 

Per the feedback from our engineering team, the root cause of the segmentation fault might be related to the kernel page size instead of the floating point unit. 

The kernel page size differences between TS-431P and TS-531P are 4K page size v.s. 32K page size.
If they use fixed 4K page size, it might cause the problem. 

Thank you.

Best Regards,
Albert Shan

I did confirm the page file is 32K on my model

#include <stdio.h>
#include <unistd.h>

int main(void)
{
int sz;
sz=getpagesize();
printf("Page size: %d\n",sz);
return 0;
}

That returns 

 

Page size: 32768
 
QNAP's feedback does seem plausible.   Any thoughts on there feedback?
 
I do wonder there justification on increasing the page size on very similar CPU's though


#27 alucryd OFFLINE  

alucryd

    Advanced Member

  • Members
  • 332 posts
  • Local time: 02:50 PM
  • LocationLille, France

Posted 09 May 2019 - 03:26 AM

We might have to take this to Microsoft. We're using a Linaro toolchain to build everything, except the dotnet runtime which comes from Microsoft. The Linaro toolchains are designed to work with virtually any ARM chip out there so I'm quite sure page size is handled correctly on our end, the fact that ffmpeg works fine is probably proof enough.



#28 heath600 OFFLINE  

heath600

    Member

  • Members
  • 20 posts
  • Local time: 08:50 AM

Posted 25 June 2019 - 07:18 PM

@alucryd

 

Any luck with finding a solution?  Have you reached out to Microsoft?  I checked the Github page for dotnet core and did not see any similar issues to comment on.

 

The latest pack I believe .20 had no change.



#29 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 134339 posts
  • Local time: 08:50 AM

Posted 01 July 2019 - 01:08 AM

@alucryd

 

Any luck with finding a solution?  Have you reached out to Microsoft?  I checked the Github page for dotnet core and did not see any similar issues to comment on.

 

The latest pack I believe .20 had no change.

 

Hi, we don't have anything new to report yet. We're still looking into it. Thanks.



#30 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 134339 posts
  • Local time: 08:50 AM

Posted 20 July 2019 - 04:00 PM

Can you try our latest betas? It probably won't be any different, but just curious. Thanks.



#31 heath600 OFFLINE  

heath600

    Member

  • Members
  • 20 posts
  • Local time: 08:50 AM

Posted 20 July 2019 - 06:41 PM

4.2.0.33 still gives the same segmentation fault when trying to launch the application.



#32 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 134339 posts
  • Local time: 08:50 AM

Posted 20 July 2019 - 06:56 PM

Ok, thanks for trying.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users