Powerline adaptor’s speeds really depend on how good and clean your electrical lines are.
I work for an ISP and I have been to many clients who have these and the results can very drastically.
One client had a weird ground loop with noise and disconnecting a ground wire at his power mast that was tied in to a coax line cleared it up.
Powerline adapters introduce all kinds of variables you could probably not even imagine.
The first thing I would do is get the Vero on the same router/switch as the NAS by either relocating the Vero or running an ethernet cable temporarily.
That basic test would tell you so much and really help you narrow down your issue.
The most important thing is that they need to be on the same circuit.
Okay, I copied one show at 500mb and one movie at 25 GB onto a usb key and stuck it directly into the Vero and tried to play them.
Same results. Both files, despite the huge file size difference, took a little over 60 seconds to begin playing. Exactly the same as reading them from the NAS. Also, as before, the log info in the upper left corner froze during that 60 seconds. Once the file starts playing, that text starts updating constantly again.
If it helps, here’s a new log at https://paste.osmc.tv/ucemutonoj
With this new info, is it still worthwhile trying to temporarily move the Vero or run a super long ethernet cable to the router?
From your logs it looks like they both started playing in less than two seconds…
2023-08-18 19:38:17.633 T:2896 info <general>: VideoPlayer::OpenFile: /media/USB Drive/Alone.S03E07.Hungry Beasts.mkv
2023-08-18 19:38:18.028 T:3076 debug <general>: CVideoPlayer::HandleMessages - player started 1
2023-08-18 19:39:37.831 T:2896 info <general>: VideoPlayer::OpenFile: /media/USB Drive/The Hobbit - M4 Book Edit (1080p).mkv
2023-08-18 19:39:38.494 T:3095 debug <general>: CVideoPlayer::HandleMessages - player started 1
Are you sure your TV isn’t just being exceptionally slow in switching modes? Maybe you could go into your player settings and just for a test turn off refresh rate switching and see what happens.
I wouldn’t think so.
Or maybe for testing focus on one of the movies and set the gui to the to same resolution and refresh rate of the video.
I also wonder @BGIYYZ you have quite some overscan corrections configured you might want to remove them and check your TV setting
1 Like
Are you sure your TV isn’t just being exceptionally slow in switching modes? Maybe you could go into your player settings and just for a test turn off refresh rate switching and see what happens.
I made Settings → Player → Videos → Adjust display refresh rate from “On start/stop” to Off and this made no difference.
Or maybe for testing focus on one of the movies and set the gui to the to same resolution and refresh rate of the video.
I’m sorry, I don’t understand what you mean by this.
I also wonder @BGIYYZ you have quite some overscan corrections configured you might want to remove them and check your TV setting
I reset the settings to 0, but it made no difference.
I remembered that the tv has a built in network browser and so I used it to attempt to play both the same tv show and movie from the NAS. Both started near instantly. This is using the same router and powerline network as the Vero, so at this point I think it’s not a network issue, though I might be wrong about that.
Is my Vero toast? Would reinstalling the OSMC help? I’d like to avoid doing that if possible, but if it’s the only other potential solution, I will.
Well as the above didn’t help this might also not make a difference. The idea was if you have a video this 1080p 25HZ to set the GUI at the same then no Refreshrate switching would happen when the video is played.
If something mysterious is happening this is always the best to do. We can continue to troubleshoot but it would take time especially as we can not see a delay in the logs. If you want to go further I suggest to enable debug logging with debug display. You then reboot twice and play one video from USB (via Videos/Files) and record that from your phone and share that video together with uploading the Log File and give us the name of the file you played.
Rather than a full reinstall you can do a bit of a check on if there is something with your userdata that is causing it by temporarily resetting that. I’m at a loss on what is going on here at this point. With refresh rate switching off it should remove the TV doing stuff from the equation and Kodi looks pretty normal in your logs.
Let’s test with Kodi default settings. Enter the following commands with an SSH connection.
systemctl stop mediacenter
mv ~/.kodi ~/kodi.bak
systemctl start mediacenter
If needed you can restore:
systemctl stop mediacenter
mv ~/.kodi ~/kodi.bk2
mv ~/kodi.bak ~/.kodi
systemctl start mediacenter
If your original setup was restored as expected and you want get rid of the unneeded clean install you can delete that with the following command.
rm -r ~/kodi.bk2
1 Like
The logs don’t match with your statement since
2023-08-18 19:38:17.628 T:2896 debug <general>: CPlayerCoreFactory::GetPlayers(/media/USB Drive/Alone.S03E07.Hungry Beasts.mkv)
...
2023-08-18 19:38:17.633 T:2896 info <general>: VideoPlayer::OpenFile: /media/USB Drive/Alone.S03E07.Hungry Beasts.mkv
...
2023-08-18 19:38:18.061 T:3076 debug <general>: CVideoPlayer::HandleMessages - player started 2
...
2023-08-18 19:38:24.665 T:2896 debug <general>: Keyboard: scancode: 0x1c, sym: 0x0d, unicode: 0x0d, modifier: 0x0
...
2023-08-18 19:38:27.435 T:2896 info <general>: CVideoPlayer::CloseFile()
2023-08-18 19:38:27.435 T:2896 debug <general>: DeleteRenderer - deleting renderer
2023-08-18 19:38:27.436 T:2896 info <general>: VideoPlayer: waiting for threads to exit
2023-08-18 19:38:27.439 T:3076 info <general>: CVideoPlayer::OnExit()
7 seconds after start of ‘Hungry beasts’ the first keyboard presses begin and the playback completely stopped after 10 seconds from the beginning … ???
The Hobbit stopped even 8 seconds after start …???
I wonder whether your skin skin.arctic.zephyr.mod has anything to do with your issue. It is an excellent idea from @darwindesign to test this first with osmc defaults and provide logs in case this can be reproduced then.
1 Like
When I see those sort of delays (multiples of 30 secs) my suspicion is some kind of code is blocking waiting for something to timeout.
That’s not right. Something is freezing the Kodi GUI updates. I’d guess some add-on is not behaving. You’ve ruled out network delays so would test clean profile (move .kodi to .kodi.bak ) as proposed by darwin.
The ~60s delay looks to be between pressing select and Kodi opening the file (hence local or network file makes no difference)
2023-08-18 19:37:15.298 T:3066 debug <general>: Thread Timer 3466326272 terminating
2023-08-18 19:37:15.308 T:2896 debug <general>: Keyboard: scancode: 0x1c, sym: 0x0d, unicode: 0x0d, modifier: 0x0
2023-08-18 19:37:15.308 T:2896 debug <general>: HandleKey: return (0xf00d) pressed, window 10003, action is Select
2023-08-18 19:37:17.353 T:2946 debug <CAddonSettings[0@script.logviewer]>: trying to load setting definitions from old format...
.
.
2023-08-18 19:38:17.628 T:2896 debug <general>: CPlayerCoreFactory::GetPlayers(/media/USB Drive/Alone.S03E07.Hungry Beasts.mkv)
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: system rules
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: matches rule: system rules
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: mms/udp
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: lastfm/shout
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: rtmp
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: rtsp
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: streams
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: dvd
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: discimage
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: sdp/asf
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: nsv
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerSelectionRule::GetPlayers: considering rule: radio
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerCoreFactory::GetPlayers: matched 0 rules with players
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerCoreFactory::GetPlayers: adding videodefaultplayer (VideoPlayer)
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerCoreFactory::GetPlayers: for video=true, audio=false
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerCoreFactory::GetPlayers: for video=true, audio=true
2023-08-18 19:38:17.629 T:2896 debug <general>: CPlayerCoreFactory::GetPlayers: added 1 players
2023-08-18 19:38:17.633 T:2896 debug <general>: Radio UECP (RDS) Processor - new CDVDRadioRDSData
2023-08-18 19:38:17.633 T:2896 debug <general>: Audio ID3 tag processor - new CVideoPlayerAudioID3
2023-08-18 19:38:17.633 T:2896 info <general>: VideoPlayer::OpenFile: /media/USB Drive/Alone.S03E07.Hungry Beasts.mkv
2023-08-18 19:38:17.633 T:3076 debug <general>: Thread VideoPlayer start, auto delete: false
2023-08-18 19:38:17.633 T:2896 debug <general>: OnPlayBackStarted: CApplication::OnPlayBackStarted
2023-08-18 19:38:17.634 T:3077 debug <general>: Thread JobWorker start, auto delete: true
2023-08-18 19:38:17.634 T:3076 info <general>: Creating InputStream
2023-08-18 19:38:17.640 T:2896 debug <general>: [Warning] CGUITextureManager::GetTexturePath: could not find texture 'progress/circle/p0.png'
2023-08-18 19:38:17.652 T:3078 debug <general>: Thread JobWorker start, auto delete: true
2023-08-18 19:38:17.652 T:2896 debug <general>: CVideoGUIInfo::InitCurrentItem(/media/USB Drive/Alone.S03E07.Hungry Beasts.mkv)
2023-08-18 19:38:17.654 T:3077 debug <general>: Loading settings for /media/USB Drive/Alone.S03E07.Hungry Beasts.mkv
2023-08-18 19:38:17.664 T:3076 debug <general>: CFileCache::Open - </media/USB Drive/Alone.S03E07.Hungry Beasts.mkv> opening
2023-08-18 19:38:17.664 T:3076 debug <general>: CFileCache::Open - </media/USB Drive/Alone.S03E07.Hungry Beasts.mkv> source chunk size is 0, setting cache chunk size to 131072
2023-08-18 19:38:17.664 T:3076 debug <general>: CFileCache::Open - </media/USB Drive/Alone.S03E07.Hungry Beasts.mkv> using double memory cache each sized 262440000 bytes
1 Like
Okay, using @darwindesign’s suggestion of testing Kodi with default settings did the trick and videos play right away as they should. I’ll just have to add the various NAS paths back and then try and change the skin to something more to my liking.
If it is helpful to someone, here is a log file playing a video file after I put Kodi back to default settings: https://paste.osmc.tv/lejukasume
Again, if anyone is interested, here is a video showing what I was experiencing. When people commented that I pushed stop after 10 seconds, this was me pushing stop after the video got around to starting, after the waiting the minute for it to actually start.
With the stock settings does the problem come back if you switch back to the skin you were using?
As far as redoing your setup I would switch back to your .kodi that you had renamed and just rename or delete guisettings.xml and see if that is enough (you have to stop mediacenter before messing with that file as it is memory resident).
I tried putting the original skin back and the problem reappeared.
Unfortunately, I got impatient and reinstalled OSMC before your reply about deleting guisettings.xml. Now I’m having issues with the Kodi repository not being found even though I’m connected to the internet.
1 Like
Updating this thread as an FYI.
I ran across the identical symptoms described by @BGIYYZ. And the mystery was definitively solved by @darwindesign in this post from my thread:
I hope someone else finds it useful before tearing out all their hair.
Many thanks again to @darwindesign.
1 Like
I’ve had the same issue of late, with speeds dropping to 900kb/s transferring from Mac to Vero. Got rid of Embury, but to no avail. Finally tried @darwindesign post, and speed back up to 32MiB/s.
Thanks.
Deleting ~/.kodi/temp and restarting Kodi is now the place I would start since it is a known issue with that folder getting too large and slowing playback start. That would avoid the need for any reconfiguration if it takes care of the problem. There has been a solutions discussed internally that should hopefully bear some fruit. Fingers crossed. I don’t recall associating that with slow network transfer speed though. Slowing down to less than a megabyte per second I would normally suspect something wrong with the network connection itself (bad cable, wifi interference, etc.).
1 Like