Don’t run to many tools during the testing as that will taint the results.
I’ve copied the test file to an ntfs formatted, unencrypted, SanDisk32 usb 3 drive (a very fast model, able to hit 100 MB/s on a PC) .
The disk throughput test using dd is as follows (I’m unsure how much the Ntfs driver is impacting this, however 44 MB/s isn’t bad for usb 2):
copied, 78.0015 s, 43.9 MB3464339968 bytes (3.5 GB, 3.2 GiB) copied, 79.0003 s, 43.9 MB3505103360 bytes (3.5 GB, 3.3 GiB) copied, 80.0001 s, 43.8 MB/s 6874019+1 records in 6874019+1 records out 3519497994 bytes (3.5 GB, 3.3 GiB) copied, 80.3474 s, 43.8 MB/s
The MediaInfo (for the first 4MB of the file, as the tool can’t handle files over 2GB) is as follows:
General Unique ID : 175543263446195514252496747264899643399 (0x8410671B526584729FBF520EC22D7807) Complete name : purgeme.bin Format : Matroska Format version : Version 2 File size : 4.00 MiB Duration : 43 min 34 s Overall bit rate : 12.8 kb/s Encoded date : UTC 2011-08-10 11:11:46 Writing application : mkvmerge v4.8.0 ('I Got The...') built on May 24 2011 03:12:58 Writing library : libebml v1.2.0 + libmatroska v1.1.0 IsTruncated : Yes Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 4 frames Muxing mode : Header stripping Codec ID : V_MPEG4/ISO/AVC Duration : 43 min 34 s Nominal bit rate : 9 261 kb/s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 23.976 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.186 Writing library : x264 core 116 r2044 392e762 Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=9261 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00 Language : English Default : Yes Forced : No Audio ID : 2 Format : DTS Format/Info : Digital Theater Systems Mode : 16 Format settings, Endianness : Big Muxing mode : Header stripping Codec ID : A_DTS Duration : 43 min 34 s Bit rate mode : Constant Bit rate : 1 509 kb/s Channel(s) : 6 channels Channel positions : Front: L C R, Side: L R, LFE Sampling rate : 48.0 kHz Frame rate : 93.750 FPS (512 spf) Bit depth : 24 bits Compression mode : Lossy Stream size : 470 MiB Default : Yes Forced : No
Is there anything else I should try, besides randomly seeking through the file from the Sandisk32 drive to try and reproduce the original error?
Does it play OK on the unencrypted drive?
This can be a completely spurious message. I have seen it using skip forward or backward even when the video file is so small that all of it fits in the Kodi memory buffer on the Vero 4K.
So far, yes, but I’ve not been able to reproduce the problem on the encrypted hard drive, so I wouldn’t read too much into it.
That’s interesting, thanks for noting that.
I sometimes have the same message and the speeds are not the problem. The movie is even buffered for minutes while I make tiny 10s jumps.
Streamed from a powerfull x86 Synology NAS on my Vero 4k which is using a gigabit usb adapter. I get the same read rate too slow message without the adapter as well.
But like I mentioned, it does not always happen. Ironically it happens the most with low bitrate files (720p or even dvd rips), where network speed is most definately not the problem. Those files are sometimes buffered for the next 30 minutes or so and yet I get that message on 10s to 1m jumps. 1080p or even 4k, I will almost never get that message.
So something very odd must be at play here… especially since Vero 4k is actually performing well, meaning the jumps are instant… it is just that ANNOYING message popping up for no reason that would make sense. So any workaround, that would get rid of the message would be great. There is nothing wrong at all with the device, my network, my other devices or the actual performance… just this ANNOYING message…
What I’m struggling to understand is why I’ve only seen this issue, two nights in a row, after 9 months of using the same drives and veracrypt version.
I’ve not updated the Vero itself since November, except to remove bluetooth audio drivers (which was 2 weeks ago)
Like nabsltd said, it can happen with a fully buffered file (and I can confirm that), which might indicate that there is actually something fishy going on with the RAM? Or maybe it is some strange bug when you have more buffered than Kodi expects. I mean 720p is the new SD, lol
Anyway, I recently watched Deep Space Nine (which is a 480p dvd rip) all over again and I always jump the 90 seconds intro that comes after 3-5 minutes and chance was 90% that I would get the message, even though nearly the whole episode was already buffered. If I do those jumps in high bit rate files (1080p and higher), the chances are 10% or below I would get that stupid message. So the content plays a huge role, just not the way you would expect it to be.
offtopic: Sam, any chance you do a sale event for the 4k+ before the UK crashes out of the EU?
I also often receive this message on files of all types and sizes when doing a quick skip of 30s even when buffered. All files ntfs drives via USB.
Now that you mentioned ntfs, I think all my low quality stuff is stored on a ntfs drive that is only attached via USB to my NAS.
I‘ll test later or tomorrow if that problem is indeed related to ntfs by copying some of those files to the internal ext4 drives.
The Vero 4K + is currently on sale; so it’s a good time to buy.
From my analysis here: it is likely our prices would drop in the event of a ‘no deal’ / WTO terms.
I don’t want to do politics on the forum however.
I’ve been getting that message since I’ve gotten a Vero 4k. I had a FireTV before with Kodi and never saw that message when skipping forward.
But I always ignore it because it’s pointless to me. I can play a 70gb UHD file over WiFi but the message will still pop up after skipping even though the video didn’t hitch for a second at all and skipped immediately without a pause or anything. I wish I could just disable that notification.
WiFi-AC, NFS share on NAS, ext4 file system.
I never had that message on my shield tv either. My ntfs tests were inconclusive. However I did not receive the message when I disabled caching alltogether… though the sampling size of those tests were not significant enough to confirm that. I really think something is up with the RAM of the Vero 4k, that sometimes reading from the cache is problematic for some reasons… but that is just a feeling I have. The fact that fast forwarding in a fully cached file can result in that message would rule out any issues with network or file system, wouldn‘t you think? Because once everything is cached to the end of the file, there should be no network or hdd activity… so my gut really believes it has to be about the cache.
But then again, the actual performance is very good… so yeah I kind of „accept“ the message as well… though I would really wish there was a way to get rid of it.
You are comparing two different devices. I don’t know a lot about Android’s buffering mechanism. But you are also comparing Fast vs Gigabit Ethernet if you are using the original 4K on your wired network.
You could change the buffer size or try ext4. I have some ideas for improving NTFS performance; but this will only work with RO mounts.
Is this a Kodi bug?
I’ve said this before, but it bears repeating - the part I cannot comprehend is why I’m only seeing this problem now.
- I purchased the Vero last April.
- I always use ntfs formatted drives.
- Veracrypt has been installed since at least last May (same version).
- The media I’m playing back has been watched on this identical setup before.
The only recent changes are:
- Updated vero’s osmc in November, after running on a test version for some time to iron out the 8bit colourspace issue
- Removed the Bluetooth audio driver (which I’d got working and promptly forgotten about as I didn’t make use of it), then began noticing stuttering on playback of all manner of media types.
Sam swiftly diagnosed this issue, and his suggestion, to remove the driver, resolved that issue two weeks ago.
I hadn’t previously noted the fact that, despite the message, vero plays everything perfectly, with only very occasional, very short buffering on very long seek operations.
I’m seeing no evidence that, even with ntfs and veracrypt overhead, the drive can’t deliver data fast enough (21MB/s throughput tested; playback averaging 1700KB/s read rate)
The tests you wrote of, disabling caching, using files small enough to be completely ram cached, were they on the Vero (I’m assuming so)?
All done on the Vero 4k (not 4k+).
But to be honest, all those tests felt kinda pointless because I had problems recreating the problem which does not surprise me because they often feel very random.
I have googled the problem and some others have it as well, different devices, nothing to do with osmc. Might indeed be a Kodi problem, so maybe it‘s gone soon anyway with Kodi 18.
Strange thing I found was it occurred two nights in a row, on the same tv series (different episodes), skipping past the opening titles after the teaser/episode start.
There’s a pattern, but it’s not reproducible so far.
Yes that covers most cases I experienced, skipping the opening titles… I mean, that is what skipping is for, there are usually not many reasons for even using skipping or fast forward.
What you can do is changing the advanced network settings in Kodi. I am currently trying different settings as well. But it is so frustrating to diagnose if any changes cure the problem with that godamn message since it is impossible to recreate it.