I’ve had this strange streaming issue on my 4k since the last update.
I’m watching something, it stops playing in the middle of it and then it’s no longer picked up by the player. After a while it can suddenly start working again so it’s not an NFS server issue.
Even stranger is that if I remove it from my library it gets scanned in again but still doesn’t work!
Afterwards I can watch any other file without having a problem but it won’t load that file for a while anymore.
At first it thought it might be the file or the drive but I can play the files with any player on the main system and there is no drive corruption found either.
Checking the kodi log file it has trouble opening the stream but nothing I can put my finger on.
14:17:14.363 T:4081902160 NOTICE: VideoPlayer: Opening: nfs://192.168.1.100/Movies/Test (2005)/Test (2005) Bluray-720p.mkv
14:17:14.363 T:4081902160 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED
14:17:14.364 T:3449811712 NOTICE: Creating InputStream
14:17:14.458 T:3449811712 ERROR: Open - failed to open source <nfs://192.168.1.100/Movies/Test (2005)/Test (2005) Bluray-720p.mkv>
14:17:14.458 T:3449811712 ERROR: CVideoPlayer::OpenInputStream - error opening [nfs://192.168.1.100/Movies/Test (2005)/Test (2005) Bluray-720p.mkv]
14:17:14.459 T:3449811712 NOTICE: CVideoPlayer::OnExit()
14:17:14.459 T:4081902160 ERROR: Playlist Player: skipping unplayable item: 0, path [nfs://192.168.1.100/Movies/Test (2005)/Test (2005) Bluray-720p.mkv]
14:17:14.472 T:4081902160 NOTICE: CVideoPlayer::CloseFile()
14:17:14.472 T:4081902160 NOTICE: VideoPlayer: waiting for threads to exit
14:17:14.472 T:4081902160 NOTICE: VideoPlayer: finished waiting
14:17:14.472 T:4081902160 NOTICE: CVideoPlayer::CloseFile()
14:17:14.472 T:4081902160 NOTICE: VideoPlayer: waiting for threads to exit
14:17:14.472 T:4081902160 NOTICE: VideoPlayer: finished waiting
Rebooting the Vero does not help, restarting the NFS server doesn’t help either, the files work and there is no corruption and the Vero does find the files after removing and scanning but doesn’t play them. That’s all options I can think of on my side.
I’ve been running this exact same setup for years with both these and different drives, same NFS setup, everything is the same as it always is but I never had any issues, it only started happening recently, around December or the beginning of January and last time it suddenly fixed itself but now it happens with another file again.
Keep in mind that I was watched the file from beginning to end, played it again and then it stopped in the middle unable to open the stream.
Hard to say without debug logging; and a full set of logs.
Perhaps an IP conflict on the network?
No IP conflict either, everything gets a forced IP to avoid any conflict and other then since it happens with just 1 file and not the entire NFS server or Vero network it seems highly unlikely.
I can queue up a list of files and it plays them all but 1 file, if I remove the file from the library it scans the directory and finds the file again but this is how the player handles it.
I also checked every form of network block that could be happening but since my router doesn’t handle this, a switch does, it’s pretty basic and nothing in it has changed either.
What part of the debug log do you need and where can I find exactly what you’re looking for (other then upload everything automatic)?
@sam_nazarko I got the remote by the way but forgot to mail you back, thanks mate, works perfectly 
Do you mean that only one specific file causes a problem?
Yes that’s the weird thing, but there is nothing wrong with the file because I watched it 10 times already, I checked my main server verified the harddisk and the file itself for corruption, and I used various internal players to test it with debug mode on. No issues.
Removing it from the library and rescanning the library even makes it add the file again.
The file itself doesn’t get loaded by the Vero anymore after stopping playback on the Vero in the middle of the file.
Last time this happened with a file it resolved itself after a few days but no matter what I do manually to find and issue or fix it, I can’t figure out the problem and it never happened before December/January with any files.
Hard to speculate without a sample (if it can be reproduced with local playback too) or debug log
That’s why I asked what part of the log you needed and which part of which log.
There is nothing wrong with the file, since neither the SHA256, or chunks of the movie changed (verified with original source) the file is the same as it was since it was created (and played back about 8 times if not more, it’s just a cartoon for the kids when they’re bored so it’s on often enough), and the file structure and directory structure have not changed either. Since there is no drive or file corruption all that is left are either transfer or playback device issues, since the transfer of other files is done just fine, the settings of the NFS server (Hanewin) have not been changed and the file - is - found during removal and rescan of the library the only logical issue could be OS or player related (it can’t even be the nfs daemon because it loads other files from the same directory structure).
That’s what makes this a real head scratcher for me, if it was a player glitch a reboot should have done the trick but multiple reboots don’t fix it either. If it was a directory structure or server connection issue the file wouldn’t even be found after a removal but it gets added again, it simply doesn’t play.
It just gave me a popup once that there where issues playing and I should check the Kodi.log, which I copy and pasted above, which clearly shows it can’t build up an input stream because it can’t reach the file, yet it can when checking the directory structure lol.
That’s why we asked for complete logs. There are multiple aspects that can be ruled out or seen as a possible cause. This is why we developed a system that provides the most useful info for debugging issues.
1 Like
That’s why we asked for complete logs.
That’s why I stopped producing logs and reporting bugs after the pastebin-like experience. They are indeed filled with everything needed but aren’t trimmed, are completely open source but filled with information (PII, timestamps etc.) not everyone likes to share. I don’t have anything to hide but we’re getting harvested without most of us knowing left and right already so knowingly adding to that fact, some people don’t mind showing their ID cards either to anyone… I don’t mind spending an hour trimming a log, leaving all required things and randomizing and removing all markers but I don’t do full automated logs out of pure policy I made for myself years ago that you might do no harm but retention always happens.
It’s not an issue I have with OSMC, it’s an issue with anything that requires full dumps or full automated log collection.
A lot of people agree with me on that part even more don’t know and a lot of people simply don’t care, I’m glad there are people that don’t care so you can still keep going while they just post their stuff and I know I simply can’t be helped by a lot of people that don’t want to, or can’t work with trimmed logs and it’s ok.
I’m sure my problem will eventually resolve itself like it did before, if it doesn’t, too bad, everything else works so it’s really a single shot issue every single time (with a for me unknown cause, and over the years I did learn a great deal about things myself as well).
Anyway thanks for trying, I had to give it a try with a minimal log 
If you are that concerned sharing your logs, you could upload it and then PM the link to the person who requested them. That would be completely private as we have no way to see the logs unless you share the link.
I know bmillham, thanks, and if the problem is there to stay and I can’t find a solution myself I’ll drop Sam or someone a line.
It’s really not that there will be much in the log that would “harm my privacy” in any way but it’s just something I don’t do, like “I don’t smoke because it’s known to cause health problems, but having one will more then likely not kill you” a bit of an overstatement in comparison but you get the idea I hope. I used to upload logs all the time! But up until the pastebin-like era.
I’d have to check with Sam, but I know that the logs are not kept forever. I think it’s only a few weeks, maybe a month.
I think it was 60 days? I’m not completely sure either! I think Sam said something like that at some point in time.
I’ve been messing around with the issue myself for the last few hours now, going through the system as far as I can, it really seems to be limited to one movie, just like it did a few weeks ago, O.O that’s why I’m trying to figure out what happens, I tried hardlinking to different directory structures but wherever I put it and no matter how many integrity and debugging I run on the video itself there is no sign of WHY it should have stopped working only on OSMC, it works fine on any players, NFS shares and anything else, it used to work perfectly fine on OSMC too. But there is a big chance that just like with the movie I had the issue with in the past it’s going to resolve itself in some magic way lol.
If I figure it out i’ll post what’s wrong but so far no luck
LOL! it’s playing right now, I changed nothing, clicked play just for the heck of it and it worked again.
I really do not understand what triggers this issue and what resolves it, it’s so strange.
It’s actually about 3 months and 1 week.
As to why it is a random problem, you could at least share media info on the file. That may give a clue.
So give or take a 100 days, we where both a bit off haha.
Format : Matroska
Format version : Version 2
File size : 6.54 GiB
Duration : 1 h 45 min
Overall bit rate mode : Variable
Overall bit rate : 8 872 kb/s
Encoded date : UTC 2010-02-16 13:11:23
Writing application : mkvmerge v2.9.8 (‘C’est le bon’) built on Aug 13 2009 12:49:06
Writing library : libebml v0.7.7 + libmatroska v0.8.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 8 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 45 min
Bit rate : 7 304 kb/s
Width : 1 280 pixels
Height : 546 pixels
Display aspect ratio : 2.35:1
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.436
Stream size : 5.25 GiB (80%)
Title : x264
Writing library : x264 core 88 r1471 1144615
Encoding settings : cabac=1 / ref=8 / deblock=1:-3:-3 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=64 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=0 / mbaff=0 / constrained_intra=0 / bframes=6 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / wpredp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=2pass / mbtree=0 / bitrate=7304 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.80
Language : English
Default : No
Forced : No
Audio #1
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 1 h 45 min
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 : 1.11 GiB (17%)
Title : DTS 5.1
Language : English
Default : Yes
Forced : No
Audio #2
ID : 3
Format : Vorbis
Format settings, Floor : 1
Codec ID : A_VORBIS
Duration : 1 h 45 min
Bit rate mode : Variable
Bit rate : 64.0 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Stream size : 48.3 MiB (1%)
Title : Commentary
Writing library : libVorbis 20090709 (UTC 2009-07-09)
Language : English
Default : No
Forced : No
Text #1
ID : 4
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : English
Default : Yes
Forced : No
Text #2
ID : 5
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : Bulgarian
Default : No
Forced : No
Hope that’s helpful, I can have a look at the other file that had symptoms previously as well if it helps.
The only thing that jumps out at me is Audio #2 being vorbis. That’s a bit unusual. It would be interesting to see of the other file you’ve had trouble with also had a vorbis audio track, or if any of your other files have vorbis.
That did look interesting to me as well but as far as I can see, I think they did the French Commentary dub in vorbis for some reason, the other file did not contain a profile with vorbis audio or anything extremely strange that jumped out for me.
Format : Matroska
Format version : Version 2
File size : 4.08 GiB
Duration : 1 h 33 min
Overall bit rate : 6 260 kb/s
Encoded date : UTC 2013-11-18 02:53:39
Writing application : mkvmerge v3.4.0 (‘Rapunzel’) built on May 15 2010 09:38:20
Writing library : libebml v0.8.0 + libmatroska v0.9.0
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 9 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 33 min
Bit rate : 4 627 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.209
Stream size : 3.01 GiB (74%)
Writing library : x264 core 135 r2345kMod f0c1c53
Encoding settings : cabac=1 / ref=9 / deblock=1:-3:-3 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=1.10:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=0 / crf=17.0000 / qcomp=0.80 / qpmin=0 / qpmax=30 / qpstep=4 / vbv_maxrate=20000 / vbv_bufsize=15000 / crf_max=0.0 / nal_hrd=none / ip_ratio=1.30 / pb_ratio=1.20 / aq=1:1.10
Language : English
Default : No
Forced : No
Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 1 h 33 min
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 : 1 006 MiB (24%)
Language : English
Default : Yes
Forced : No
Text #1
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : English
Language : English
Default : No
Forced : No
Text #2
ID : 4
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : English-SDH
Language : English
Default : No
Forced : No
Text #3
ID : 5
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : Dutch
Language : Dutch
Default : No
Forced : No
Text #4
ID : 6
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : French
Language : French
Default : No
Forced : No
Text #5
ID : 7
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : German
Language : German
Default : No
Forced : No
Text #6
ID : 8
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : Portuguese
Language : Portuguese
Default : No
Forced : No
Text #7
ID : 9
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : Spanish
Language : Spanish
Default : No
Forced : No
Menu
00:00:00.000 : en:Chapter 1
00:00:32.824 : en:Chapter 2
00:02:28.690 : en:Chapter 3
00:05:16.566 : en:Chapter 4
00:07:55.392 : en:Chapter 5
00:10:59.617 : en:Chapter 6
00:14:23.196 : en:Chapter 7
00:18:28.649 : en:Chapter 8
00:20:12.628 : en:Chapter 9
00:21:01.469 : en:Chapter 10
00:25:29.987 : en:Chapter 11
00:28:21.325 : en:Chapter 12
00:32:08.927 : en:Chapter 13
00:35:20.744 : en:Chapter 14
00:39:12.308 : en:Chapter 15
00:44:26.247 : en:Chapter 16
00:48:29.156 : en:Chapter 17
00:51:32.548 : en:Chapter 18
00:53:47.391 : en:Chapter 19
00:55:20.651 : en:Chapter 20
00:57:49.633 : en:Chapter 21
01:01:18.341 : en:Chapter 22
01:03:47.615 : en:Chapter 23
01:07:44.978 : en:Chapter 24
01:10:27.890 : en:Chapter 25
01:15:17.513 : en:Chapter 26
01:17:08.457 : en:Chapter 27
01:19:13.332 : en:Chapter 28
01:20:55.100 : en:Chapter 29
01:23:44.478 : en:Chapter 30
01:26:01.239 : en:Chapter 31
01:27:03.176 : en:Chapter 32
Maybe the CABAC profile? But that isn’t that rare I think.
We will have no idea without a log.
I want to get this fixed for you but I’ve not got a lot to look at currently.
The logs cannot be accessed unless a link is publicly posted, so you could always sanitise and post us the final version.
Sam
Possibly a quick test you could do yourself, get mkvmerge, remux it with everything, but also remux without the vorbis if that might be causing the problem. Looks like an extremely old version of mkvmerge was used on it.
Not saying it’s the issue but it’s something you can try yourself and sometimes I’ve found remuxing can fix odd issues like this.