It would be nice to have a comment from Roon team
Yes still happening on my android tablet. Roon âhomeâ takes 20-25 seconds to load.
P.S takes about 3 second on windows PC endpoint the first time, then instantaneous after that.
1 Like
Exact same thing. It looks like an Android app issue.
Not taking that long on my M11 DAP same as any other device which between 3-5 secs. Maybe a regional CDN issue causing the delay.
I added some ram, I even installed a faster ssd for the DB and (for backup purpose) added an internal ssd to store music file inside my Rock server. No change.
I think it is a performance issue on the android app. Can someone from Roon team comment?
This is likely then to be an ISP/ CDN issue or Roons servers are underperforming at times. They can exhibit issues that only certain areas see it, happened before and it took a long time before they realised it was their end and every man and his dog will blame your network. I have noticed search has got considerably slower recently so may be some load issues somewhere. Also wonder if the recent cloudflare meltdown is still having ripple affect. My Android DAP is still pretty quick so unlikely an Android issue unless the network stack on the device is susceptible and mine isnt.
Do you have an explanation for why this slowness doesnât apply equally to everyone, in the same area? What can be the cause of the fact that I have zero problems:
@Bluebeat, however, has a lot of trouble even though we both live in Germany?
Itâs really annoying, Iâm sorry.
No such problem here, by any means.
Is it possible that the issue is caused by the device itself and not the Android app?
Like a phoneâs performance slowing down after times, with numerous apps installed, plenty of junk files, not enough RAM, running out of storage âŚ
Maybe an Android performance test could help to clarify that, I only know geekbench?
Timings. When they moved to 1.6 and the start of Roon using the Cloud more, search and page loading got very slow but it was intermittent and as a result some people where like ? its fine for me. But then after a while when more users started to see it at certain times yet others still unaffected the penny started to drop. It took over 6 months of a large thread for Roon to finally admit it was the back end and sort it. Itâs done it several other times since and they have needed to upgrade their side to cope with increased loads 1.8 there was a big meltdown. It always would be worse late at night when you had UK and US all awake. It was a load issue where you could use it one minute and it was fine the next time it would take like 20-30 secs to return anything all down to it being overloaded at that point in time, return again minutes later and its fast as as it should be. Add in local CDN/ISP issues (not all dns respond the same) then it can be compounded.
1 Like
Hi @Judelow,
Just checking in. Did you ever get past the slowness? If youâre still experiencing the same issues, can you get me a date/time/track being played instance for me to investigate further?
Thanks,
Wes
Thanks for your answer.
Yes I am still experiencing the same issue.
It happens when I open the app , it takes long time to display the home display correctlyâŚ
You can check any time? How can I more precisely answer your request?
Hi @Judelow,
Will you recreate and tell me the date/time? I will look at diagnostics logging and see what Roon sees as happening in the background.
Thanks,
Wes
Ok I will try.
I dont know if it is linked to diagnostic mode, but I cannot access my core anymore, with roon app or directly with its IP address on my LAN.
It is just back
Hi @Judelow,
I hadnât done anything so Iâm not sure why it appeared offline for that time. I am seeing some errors in your logging that indicate there may be a hardware problem though. Hang tight. I am going to review the logging with my teams and see what I can do to offer assistance from there.
Regards,
Wes
Hi @Judelow,
I have found some hardware errors in your diagnostics logging that indicate youâre either looking at a bad NVMe or a board issue with your NUC.
The errors listed here match your logging:
Feb 7 17:47:14 (none) user.err kernel: [ 13.411960] ata1.00: exception Emask 0x10 SAct 0x8ffe00 SErr 0x400101 action 0x6 frozen
Feb 7 17:47:14 (none) user.err kernel: [ 13.411966] ata1.00: irq_stat 0x08000000, interface fatal error
Feb 7 17:47:14 (none) user.err kernel: [ 13.411968] ata1: SError: { RecovData UnrecovData Handshk }
Feb 7 17:47:14 (none) user.err kernel: [ 13.411971] ata1.00: failed command: WRITE FPDMA QUEUED
Feb 7 17:47:14 (none) user.err kernel: [ 13.411973] ata1.00: cmd 61/40:48:60:0d:c4/05:00:e8:00:00/40 tag 9 ncq dma 688128 out
Feb 7 17:47:14 (none) user.err kernel: [ 13.411973] res 40/00:58:e0:17:c4/00:00:e8:00:00/40 Emask 0x10 (ATA bus error)
Feb 7 17:47:14 (none) user.err kernel: [ 13.411979] ata1.00: status: { DRDY }
Feb 7 17:47:14 (none) user.err kernel: [ 13.411981] ata1.00: failed command: WRITE FPDMA QUEUED
Feb 7 17:47:14 (none) user.err kernel: [ 13.411982] ata1.00: cmd 61/40:50:a0:12:c4/05:00:e8:00:00/40 tag 10 ncq dma 688128 out
Feb 7 17:47:14 (none) user.err kernel: [ 13.411982] res 40/00:58:e0:17:c4/00:00:e8:00:00/40 Emask 0x10 (ATA bus error)
Feb 7 17:47:14 (none) user.err kernel: [ 13.411987] ata1.00: status: { DRDY }
Feb 7 17:47:14 (none) user.err kernel: [ 13.411989] ata1.00: failed command: WRITE FPDMA QUEUED
Feb 7 17:47:14 (none) user.err kernel: [ 13.411990] ata1.00: cmd 61/40:58:e0:17:c4/05:00:e8:00:00/40 tag 11 ncq dma 688128 out
Feb 7 17:47:14 (none) user.err kernel: [ 13.411990] res 40/00:58:e0:17:c4/00:00:e8:00:00/40 Emask 0x10 (ATA bus error)
Feb 7 17:47:14 (none) user.err kernel: [ 13.411995] ata1.00: status: { DRDY }
Feb 7 17:47:14 (none) user.err kernel: [ 13.411997] ata1.00: failed command: WRITE FPDMA QUEUED
Feb 7 17:47:14 (none) user.err kernel: [ 13.411998] ata1.00: cmd 61/40:60:20:1d:c4/05:00:e8:00:00/40 tag 12 ncq dma 688128 out
Feb 7 17:47:14 (none) user.err kernel: [ 13.411998] res 40/00:58:e0:17:c4/00:00:e8:00:00/40 Emask 0x10 (ATA bus error)
Feb 7 17:47:14 (none) user.err kernel: [ 13.412003] ata1.00: status: { DRDY }
Feb 7 17:47:14 (none) user.err kernel: [ 13.412004] ata1.00: failed command: WRITE FPDMA QUEUED
Feb 7 17:47:14 (none) user.err kernel: [ 13.412005] ata1.00: cmd 61/40:68:60:22:c4/05:00:e8:00:00/40 tag 13 ncq dma 688128 out
Feb 7 17:47:14 (none) user.err kernel: [ 13.412005] res 40/00:58:e0:17:c4/00:00:e8:00:00/40 Emask 0x10 (ATA bus error)
Feb 7 17:47:14 (none) user.err kernel: [ 13.412010] ata1.00: status: { DRDY }
The best advice we have to offer is to backup your databases and reload ROCK on a new drive. Itâs going to be the cheaper of the options between replacing the SSD and the board.
Please let me know if you have any questions.
Regards,
Wes
Can you please retest? At that time,I noticed the server was not running as usual. After reboot, it got back to how it was.
The ssd is new. It is strange. I changed it for a faster one few weekd ago.
NB : my DB is saved on my NAS so there should ve no issue to get it back if needed
Hi @Judelow,
Thereâs not any testing happening. These are errors when we try to communicate with the NUC. The same errors are present and there are new ones. This is from the article I shared with you prior. These errors are not normal and are quite problematic for Roon ROCK.
An âATA bus errorâ generally implies an issue with SATA interface. This could be a hardware issue of SATA interface on the unit and/or the hard disk, and it could be a firmware/software issue on the unit and/or the hard disk. In addition, poorly seated hard disk and insufficient power supply may cause this error.
Feb 7 17:47:15 (none) user.err kernel: [ 14.405154] ata1.00: failed command: WRITE FPDMA QUEUED
Feb 7 17:47:15 (none) user.err kernel: [ 14.405155] ata1.00: cmd 61/40:f8:a0:90:c4/05:00:e8:00:00/40 tag 31 ncq dma 688128 out
Feb 7 17:47:15 (none) user.err kernel: [ 14.405155] res 40/00:e0:60:8b:c4/00:00:e8:00:00/40 Emask 0x10 (ATA bus error)
Feb 7 17:51:05 (none) user.notice roonserver/run: TIFFReadDirectory: Failed to read directory at offset 24813990.
Feb 7 17:51:05 (none) user.notice roonserver/run: TIFFFetchDirectory: Memory: Can not read TIFF directory count.
Regards,
Wes
1 Like
Thanks,
I have added 4To Samsung 870 QVO MZ-77Q4T0BW on my NUC7I7DNHE to store my music internally. Is it the one causing issues? What can I do? Is it compliant with my NUC? I have a cooy of my music on a NAS, I could make Rock point toward the NAS and see if it changes any thing?
What can I do about the power supply?
Please note, I have a samsung NVMe 990 pro to store the database. Is that one causing issues as well? I still have the previous one, I can put it back.
Do we know the possible consequences of these issues as I am still able to play music?
What is the procedure to follow?
If your current power supply is not below this standard, youâre good.
19 V 65 W
If itâs more, it doesnât matter. 90 W is also good.
https://www.intel.com/content/www/us/en/support/articles/000007053/intel-nuc/intel-nuc-kits.html
@Judelow
I just remembered what you said earlier:
Could it be that something went wrong when installing it in the Akasa case? A cable not properly connected, a contact not quite right?