[fritsch]

 I can't say the same thing for the Nvidia Shield (random stopping of the movie and now the ProjectM visualizer causes skips in music when it changes patterns for some odd unknown reason).

I think that's fixed in master already. Same as audio stutters if you play music with kodi and go to the android home screen.

[VonMagnum]

18.5 just stopped playing a movie after 1 hour and 2 minutes for no apparent reason.  Hopefully, 18.6 might have it fixed.

[fritsch]

It won't for sure - such reports are worth absolutely nothing. My last movie played 2 hours and 30 minutes. Does that help you?

If you want to get bugs solved, reproduce with debuglogging, open a proper github issue.

[Pirivan]

 I can't say the same thing for the Nvidia Shield (random stopping of the movie and now the ProjectM visualizer causes skips in music when it changes patterns for some odd unknown reason).

I think that's fixed in master already. Same as audio stutters if you play music with kodi and go to the android home screen.  

First let me say thanks to all of the awesome devs that work on Kiodi and spend their valuable time on the forums answering questions and attempting to troubleshoot difficult issues like this; your effort is much appreciated.  In particular posts by @fritsch were really helpful in trying to understand how to approach finding a work around/resolution for this issue.  Also appreciate posts from user @sullysnet detailing his efforts to try to work around the issue.

I am experiencing the same issue as described in this thread on my NVIDIA Shield TV 2015 model (latest firmware/Android 'released' Shield TV OS installed, 8.0.1 not including any beta or hotfixes) when using SMB3.0 on my QNAP TVS-873 NAS and within Kodi 18.5.  SMB shares are mounted in Kodi not from within the Shield TV.  Video playback stops after either 10 minutes or roughly 40min-1hr 10min, with the following error in the debug log when the problem occurs: ERROR: Read - Error( -1, 103, Software caused connection abort.

Below is what I have researched so far in case it is of help to anyone in the future.  I poured through a number of threads as well as located an open github issue describing a very similiar problem (links listed below in case anyone else is researching this as well):https://forum.kodi.tv/showthread.php?tid=324746
https://forum.kodi.tv/showthread.php?tid=346462
https://forum.kodi.tv/showthread.php?tid=347265
348860 (thread)
15241 (GH issue)

The possible resolutions I compiled from various threads are as follows, noting which solutions I have attempted so far. I picked which order to implement solutions based on what made sense to me:

Disable IPv6 and network discovery in the NVIDIA Shield OS
Tried this, no impact.

Enable only SMBv3 on the QNAP and within Kodi
Tried this, no impact.

Enable only SMBv1 on the QNAP and within Kodi
Tried this, no impact.

Use Kodi Android Installer addin in Kodi to upgrade to latest 18.5 nightly build
Tried this, no impact.  At the time that was: kodi-20191226-51eff914-Leia-arm64-v8a.  I tried this because I misunderstood what was previously stated about the issue being fixed in master and assumed that it was meant that the issue was addressed in the latest 18.5 build.  This was a waste of time I am sure due to my ignorance of the way Kodi builds work.

Use 'Kodi Android Installer' addin within Kodi to upgrade to the latest nightly master build, which is an alpha of 19.0 (in this case that is/was kodi-20191229-4cb3dd66-master-arm64-v8a)
I attempted this fix purely because @fritsch thought that the thought the issue might be resolved in master.  This APPEARED to resolve my issue at first, and a playback succeeded beyond 1hr or so on my FIRST test but the issue re-occurred on subsequent playback tests.  There are a ton of caveats here in case anyone is thinking of attempting this solution.  First, many addins will likely not work in the alpha Kodi 19 Matrix master build.  In fact the 'Kodi Android Installer' addin itself isn't even supported and I had to uninstall it so now I need to download new nightlies apk's onto the Shield and install them manually.  I am using a pretty new vanilla/default install of Kodi so I felt that trying the alpha was fairly low risk.  Second word of warning, the master is an alpha and may be completely unstable as the devs are testing new features so only try this at your own risk if you have a backup (or are OK starting over fresh if you have to) and don't want to attempt the other fixes.

Update Shield TV 2015 to latest NVIDIA hotfix -> set Shield developer option for logger cache to 16MB -> mount the SMBv3 shares on the QNAP from the Shield (not form within Kodi) -> present shares as local storage in Kodi -> re-create the media sources in Kodi
Did not attempt.  I did not like that there is no rollback procedure from the NVIDIA hotfix, plus there doesn't even appear to be a way to 'get off' of the hotfix branch once you are on it and again some effort would need to be taken to export my watched information etc. if I removed my sources in Kodi which is a bit of a pain.  I think this is very likely to work as it appears to be the only "verified" as working fix that helped users in thread 348860.  I think the reason this works is that it allows you to use a different/"fixed" Android implementation of SMB that is not yet available in Kodi.  This also may ONLY apply to Shield TV 2017/2019 models that I do not own, they have 3 hotfixes available with different release notes, there are only 2 hotfixes for the 2015 model.  That is another reason I have not yet attempted this fix.

Swap shares on QNAP from SMB to NFS and/or enable NFS on QNAP shares
Did not attempt.  Based on comments from devs in other threads if feels like using NFS is the "recommended" solution.  However, I was concerned that enabling both SMB AND NFS on my QNAP might impact the shares/access from Windows AND others reported that the issue still occurred when using NFS.  Also, this would entail exporting watched information/doing a library export/editing the sources.xml file as Kodi will view the shares as 'new' sources. I wanted to avoid doing this unless I had more confidence it might work.

Disable CEC
Did not attempt, sounds like this previously fixed a similar problem but no longer is the resolution in 18.5, I also think I may have CEC already disabled anyhow.

Set static IP for Android
Did not attempt, I have a DHCP assignment for my Shield TV on my router and I am not sure this will really work.

Swap to 2.4Ghz instead of 5Ghz connection for Shield TV
Did not attempt, I really don't want to use 2.4Ghz for performance reasons as 5Ghz is many times higher performance than 2.4Ghz for another device in the same location.  I can't use Ethernet due to the location of the NAS/Shield TV but I could temporarily use it if required.  I absolutely understand why network drops for poor 5Ghz signals could cause this issue but I am doubtful this is causing my issue.

Setup buffering/video cache for streaming in Kodi via editing advancedsettings.xml
Did not attempt.

My next fix attempt will likely be to mount the SMB shares in Android, present them to Kodi and backup/restore my watched information (I may need to revert to 18.5 first and restore config backup so that I can use the watchedInformation backup addon).  I will try to do this and test without installing the NVIDA Shield hotfix (given my reasons above) and see if works before considering getting onto the hotfix branch.  I will update this post if I appear to actually locate a fix for my hardware configuration.  Hopefully this has been helpful to someone.
 
 @fritsch Sorry to trouble you but would it be possible for you to link me to where you noticed the SMB related fix for Android in master?  I tried searching for it on github but I was unable to locate it. It would be really helpful for me to follow along with the dev conversation about the fix.

[fritsch]

2 questions:
a) Did master fix your audio issue?
b) It had to do with the FileCache. There is a small outtage at the moment for small files, but this is actively being worked on. If jenkins is happy, I will push that stuff in some hours. Then tomorrow's nightly will have it. What we backport to Leia needs to be decided - too many things can go wrong :-(

[Pirivan]

2 questions:
a) Did master fix your audio issue?
b) It had to do with the FileCache. There is a small outtage at the moment for small files, but this is actively being worked on. If jenkins is happy, I will push that stuff in some hours. Then tomorrow's nightly will have it. What we backport to Leia needs to be decided - too many things can go wrong :-(

@fritsch Thanks for the quick reply, much appreciated!  In answer:
a) I am unsure if I am impacted by the audio issue.  My music tags are a mess as it turns out (I need to fix everything with MusicBrainz) so I have not added my music library to Kodi .
b) Very interesting about the FileCache issue.  Excellent news on a possible fix being pushed (your efforts are really appreciated, that's an amazing turn around time).  I will update and test ASAP when I see a new nightly available.  Totally understood about not wanting to risk backporting to Leia and compromising stability on that build.  If I need to continue to run the v19 alpha to use the fix until I can upgrade to the official v19 release sometime next year that's a totally understandable trade off.

[VonMagnum]

It won't for sure - such reports are worth absolutely nothing. My last movie played 2 hours and 30 minutes. Does that help you?

If you want to get bugs solved, reproduce with debuglogging, open a proper github issue.

I was only replying to your prior post that implied it might be fixed, not trying to debug with that comment.  Your post didn't specifically indicate in which version (18.5 didn't fix random stops OR the skips with ProjectM, neither which existed before the last major Shield firmware update.  I assumed people have already given debug reports with the error given how common it is on the NVidia forums and your post that it might be fixed. 

I'll try to get a debug report when I get a chance (with Family coming up for the holiday I need to just play movies for now not stop to get debug reports so I probably won't even use the Shield). 

Given how the Shield's main menu often shows "unknown playing" icons when KODI is running but not doing anything, I can only assume there's some odd interaction going on there with whatever function in the Shield displays music currently playing in a guest program as I don't think it should be showing music playing when it's not.  Maybe it gets confused with the "dead silence" option or something and assumes it's still playing long after it stopped?  I haven't tried switching that off). 

Overall, given this issue ONLY affects Android (it never does it on my FireTV ever) and it only seemed to start with the last major NVidia Shield firmware update, I'm assuming the issue is related to the firmware update, not necessarily in KODI itself, although I suppose there must be some interaction.  Previously, it appeared to be some kind of incidental CEC command in the system that caused KODI to randomly stop when it happened.  Shutting off CEC entirely got rid of the problem, but as of the last firmware update, CEC commands have changed (there are now many more than before to turn off and I suspect there may be one or two that are not being shut off despite it showing them all off as this is the same behavior as before they changed the firmware and it was absolutely CEC commands somehow causing it the last time.)

Zidoo X9S running 17.6 on the same system (using SMB to MacOS) has its own quirk; it often gets a video "freeze" instead that lasts several seconds and then resumes playing instead of stopping, but given that's what the Shield used to do when I ran Krypton on it, I'm guessing there could be a connection between the two with merely the behavior changing to stop playing rather than freezing up.  A lot of these things also coincided with an upgrade to my Mac server to a solid state hard drive and the newer operating system so I thought the freezes might be do to that (couldn't test Windows 10 with Krypton as it didn't support SMB3, but Windows 10 makes no difference with 18.5 using SMB3 instead of the Mac using SMB3).  But then I've had the Zidoo temporarily "freeze" for a few seconds using its own internal player directly off a local USB3 NTFS hard drive when playing back 3D movies (maybe once every three movies or so on average) so it's not like other software players are perfectly stable either.

My FireTV 4K did exhibit the random "freeze" issue with 17.6, though, but at least part of that was some changed settings in the Mac's "sleep" mode (it would freeze when the Mac went to sleep, which it's not supposed to do when using SMB, but the OS update screwed that up as Apple likes to screw a lot of things up).  The FireTV 4K seems almost 100% stable with 18.5 on the same system now.  I've never seen it freeze or stop.  The only issue it exhibits is the Android hardware playback bug where AVI files sometimes play "choppy" with hardware acceleration turned on, but smooth with it off (apparently a known issue that in 17.x disabled hardware acceleration automatically when AVI playback was chosen, but no longer does for some odd reason in 18.5.  I mean if the hardware playback for AVI is broken, it's broken.  Why enable it?  I have to leave hardware acceleration off when watching older AVI files now or it's not smooth).

[Pirivan]

Overall, given this issue ONLY affects Android (it never does it on my FireTV ever) and it only seemed to start with the last major NVidia Shield firmware update, I'm assuming the issue is related to the firmware update, not necessarily in KODI itself, although I suppose there must be some interaction.  Previously, it appeared to be some kind of incidental CEC command in the system that caused KODI to randomly stop when it happened.  Shutting off CEC entirely got rid of the problem, but as of the last firmware update, CEC commands have changed (there are now many more than before to turn off and I suspect there may be one or two that are not being shut off despite it showing them all off as this is the same behavior as before they changed the firmware and it was absolutely CEC commands somehow causing it the last time.)

I will admit to ignorance of HDMI CEC (and any of the issues that previously created), but if mounting the shares directly on the NVIDIA Shield 2019 model resolved the playback issue as @sullysnet describes (in this thread: https://forum.kodi.tv/showthread.php?tid=348860&page=3), would HDMI CEC be related?  If I understand correctly implementing that "fix" points to some sort of SMB issue as the culprit but again I could be way off base.

Have you tried mounting the shares from the NVIDIA Shield and then presenting those as 'local' shares to Kodi?  Did that resolve the issue for you?

I just attempted to mount the shares from the Shield and then playback a file in Kodi and still had playback halt after 23 minutes.  This is using SMBv3 on the QNAP NAS and within KODI.  I have not installed the latest NVIDIA Shield 2015 hotfixes.

I think before jumping onto the latest NVIDIA Shield 2015 hotfix I will wait for @fritsch to push out the latest v19 master nightly and see if that resolves my issue.  There are ways to reinstall/restore settings and move away from the Kodi v19 branch but according to the NVIDIA forum post there isn't a way to leave the hotfix process once you join it (which is pretty insane if you ask me).

Link to the Shield TV 2015 hofitx below in case that is helpful to anyone, again there is a DIFFERENT hotfix for Shield TV 2019:
https://www.nvidia.com/en-us/geforce/for...tfix-imag/

[VonMagnum]

It stopped playing with NFS too so as far as I can tell, it has nothing to do with SMB or NFS or perhaps networking in general, even.  I suppose I could transfer a movie to the Shield's hard drive and see if stops playing stored on the Shield itself or not.  The music library I have IS stored on the Shield and that doesn't stop it from skipping when using the Project M visualizer (doesn't skip playing local hard drive material if I do not use that visualizer, but it will skip eventually if I play music from my server over the network (both NFS and SMB have the same issue).  It's like it needs buffering memory it doesn't have.  I've never had iTunes library songs skip even on a 2006 Apple TV because it buffers them to local memory/drive as fast as it can download it, not try to "stream" it like molasses in real time (where any network hiccup whatsoever could cause it to skip).  Movies at least buffer some to avoid hiccups, but I'm under the impression music buffers little if at all by comparison.  And yes it skipped using Windows 10 SMB3 or Mac SMB 1, 2 or 3 and NFS as well. 

It's not the protocols themselves as far as I can tell, but a lack of buffering or the like that makes it crap out with the slightest fluctuation.  I don't recall seeing any buffer setting to add for music over the years that did anything, at least.  The developer that makes MrMC once said he would look into adding some buffering to fix it and make the changes available for Team KODI, but I think he's been too busy putting it on every device he can, etc. to bother with music.

[Pirivan]

Brief update with some success. I enabled ONLY SMBv1 on my QNAP NAS (set that to the max/min version, so v2 or v3 cannot be used) and then mounted the share within the Shield TV and tested playback.  I believe in the latest version of the Shield TV OS it would automatically use SMBv3 if it is available on the server you are connecting it to, that is why I had to force it to v1.  The playback did not quit for the first time during a 4K movie BUT during certain parts of the movie the Kodi UI would semi-frequently show a round Kodi UI timer/loading countdown that I have never seen before when using SMBv3 (buffering?) BUT playback did not quit/stop.  Either way, this is the closest to an actual "fix" of anything I have attempted.

So, while SMBv1 is working WHEN the shares are mounted from the NVIDIA Shield, it creates 2 negative drawbacks.  First, the buffering issue (might be a coincidence) is undesirable but it's possible that won't happen very often.  Second, with SMBv1 ONLY allowed on my QNAP NAS, my Windows 10 PC can no longer access the QNAP as SMBv1 is disabled now in Windows, which is really not going to work for my environment.  I know, there are ways I can enable SMBv1 in Windows 10 (for now) but I would prefer not to do that.

My next plan is to test the master that was just released, kodi-20191231-6e15fcb9-master-arm64-v8a and see if any of the SMB related fixes made it into this release.

 If that doesn't work, I will likely try to get the NVIDIA Shield 2015 hotfix and test to see if that allows SMBv3 to work properly (shares mapped in the Shield OS or from within Kodi).

[VonMagnum]

Brief update with some success. I enabled ONLY SMBv1 on my QNAP NAS (set that to the max/min version, so v2 or v3 cannot be used) and then mounted the share within the Shield TV and tested playback.  I believe in the latest version of the Shield TV OS it would automatically use SMBv3 if it is available on the server you are connecting it to, that is why I had to force it to v1.  The playback did not quit for the first time during a 4K movie BUT during certain parts of the movie the Kodi UI would semi-frequently show a round Kodi UI timer/loading countdown that I have never seen before when using SMBv3 (buffering?) BUT playback did not quit/stop.  Either way, this is the closest to an actual "fix" of anything I have attempted.

So, while SMBv1 is working WHEN the shares are mounted from the NVIDIA Shield, it creates 2 negative drawbacks.  First, the buffering issue (might be a coincidence) is undesirable but it's possible that won't happen very often.  Second, with SMBv1 ONLY allowed on my QNAP NAS, my Windows 10 PC can no longer access the QNAP as SMBv1 is disabled now in Windows, which is really not going to work for my environment.  I know, there are ways I can enable SMBv1 in Windows 10 (for now) but I would prefer not to do that.

My next plan is to test the master that was just released, kodi-20191231-6e15fcb9-master-arm64-v8a and see if any of the SMB related fixes made it into this release.

 If that doesn't work, I will likely try to get the NVIDIA Shield 2015 hotfix and test to see if that allows SMBv3 to work properly (shares mapped in the Shield OS or from within Kodi).

The Mac can use SMB1 automatically.  You can just set KODI Leia to accept SMB1 only and it will function here.  That did not stop the random "stops" for me, however.  I had one movie make it (1.5 hours) before.  A two hour movie failed next and then the next movie failed at 40-some minutes.  

I do recall that leaving a connection between my server (mac) and the hard drive on the Shield (via Finder to transfer files to the Shield or back from it) also caused pausing/freezing behavior before or the like, but it cleared up so long as I ejected the network connection to the Shield after I was done transferring files instead of leaving it active.  I don't know if the newer firmware for the Shield might have some kind of newer network action going on that causes a similar disruption or not.  I cannot turn off "allow file transfers" without making it a PITA to turn it back on again.  I have no Shield mounted drives currently.  I did before but it didn't seem to affect anything.  I ejected them just in case, but no improvement.

[Bitpusher]

Maybe not related but my Kodi 18.4 and 18.5 had random crashes too. After trying a lot as well my problem was caused by a very large zip file (10GB+) on one of my shares. I noticed this when I enabled debugging and the last entry before the crash mentioned this zip file. I believe it was via upnp.

[Pirivan]

Brief update with some success. I enabled ONLY SMBv1 on my QNAP NAS (set that to the max/min version, so v2 or v3 cannot be used) and then mounted the share within the Shield TV and tested playback.  I believe in the latest version of the Shield TV OS it would automatically use SMBv3 if it is available on the server you are connecting it to, that is why I had to force it to v1.  The playback did not quit for the first time during a 4K movie BUT during certain parts of the movie the Kodi UI would semi-frequently show a round Kodi UI timer/loading countdown that I have never seen before when using SMBv3 (buffering?) BUT playback did not quit/stop.  Either way, this is the closest to an actual "fix" of anything I have attempted.

So, while SMBv1 is working WHEN the shares are mounted from the NVIDIA Shield, it creates 2 negative drawbacks.  First, the buffering issue (might be a coincidence) is undesirable but it's possible that won't happen very often.  Second, with SMBv1 ONLY allowed on my QNAP NAS, my Windows 10 PC can no longer access the QNAP as SMBv1 is disabled now in Windows, which is really not going to work for my environment.  I know, there are ways I can enable SMBv1 in Windows 10 (for now) but I would prefer not to do that.

My next plan is to test the master that was just released, kodi-20191231-6e15fcb9-master-arm64-v8a and see if any of the SMB related fixes made it into this release.

 If that doesn't work, I will likely try to get the NVIDIA Shield 2015 hotfix and test to see if that allows SMBv3 to work properly (shares mapped in the Shield OS or from within Kodi).

Since my last post, I have tested the following:

• Updated to the latest NVIDIA Shield 2015 Hotfix
  • No impact, issues continue even when shares are mounted from the Shield and not from within Kodi
    
• Tested with most of daily master nightlies as they were released
  • No impact, issues continue after random intervals (10 mins, 40 minutes, 1hr 10 minutes etc.).  Playback also halts at random intervals for non 4K material (1080p or 720p)
    
  • The error in the logs seems to have changed slightly after installing the various nightly masters/installing the NVIDIA Shield 2015 hotfix and now shows the following when playback exits to the video selection UI:
    • Consistent error: 2020-01-02 17:24:08.638 T:20100  NOTICE: CVideoPlayerAudio:rocess - stream stalled
      
    • However, it does still occasionally show the previous error as well: 2020-01-02 20:23:47.913 T:8710   ERROR: Read - Error( -1, 103, Software caused connection abort )
      
  • I have not tested with the most recent nightly: kodi-20200102-e2287cde-master-arm64-v8a
    
• Forced the QNAP NAS to only allow SMBv1 and then tested playback from shares mounted from the Shield (thus forcing the Shield to use SMBv1 as well).  After several tests I can conclude that this "solves" the issue and playback no longer completely halts and exits back to the video selection menu.
  • However, this 'fix' comes with a trade-off/new "problem".  The 4K video I am using to test fairly frequently 'buffers' and displays a loading timer/circle that never occurs when using SMBv3.  The following appears in the debug logs when this loading timer is shown:
    

xml:
2020-01-03 16:11:37.110 T:13990  NOTICE: CVideoPlayerAudio:rocess - stream stalled

2020-01-03 16:11:37.148 T:13978   DEBUG: CVideoPlayer::SetCaching - caching state 1

2020-01-03 16:11:37.149 T:13978   DEBUG: CDVDClock::SetSpeedAdjust - adjusted:0.000000

2020-01-03 16:11:37.149 T:13990   DEBUG: CDVDAudio:ause - pausing audio stream

2020-01-03 16:11:40.537 T:13978   DEBUG: CVideoPlayer::SetCaching - caching state 2

2020-01-03 16:11:40.537 T:13978   DEBUG: CDVDClock::SetSpeedAdjust - adjusted:0.000000

2020-01-03 16:11:40.538 T:13978   DEBUG: CVideoPlayer::SetCaching - caching state 3

2020-01-03 16:11:40.538 T:13990   DEBUG: CDVDAudio:ause - pausing audio stream

2020-01-03 16:11:40.538 T:13990   DEBUG: CDVDAudio::Resume - resume audio stream

2020-01-03 16:11:40.540 T:13911   DEBUG: ActiveAE - start sync of audio stream

2020-01-03 16:11:40.542 T:13978   DEBUG: CDVDClock::SetSpeedAdjust - adjusted:0.000000

2020-01-03 16:11:40.543 T:13978   DEBUG: CVideoPlayer::SetCaching - caching state 0

2020-01-03 16:11:40.543 T:13978   DEBUG: CDVDClock::SetSpeedAdjust - adjusted:0.000000

2020-01-03 16:11:40.732 T:13911   DEBUG: ActiveAE::SyncStream - average error of 130.933369, start adjusting

2020-01-03 16:11:40.827 T:13911   DEBUG: ActiveAE::SyncStream - average error 10.933369 below threshold of 30.000000

2020-01-03 16:11:41.997 T:13990   DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-18290.976898, adjusted:-18290.976898

Looking at another user thread with a similar issue (https://forum.kodi.tv/showthread.php?tid=350558&page=3) I think my next attempt might be to re-enable SMBv3 on the QNAP and then test with mrmc instead of Kodi to see if libsmb used by mrmc allows playback to function without any issues.  This won't really be a "solution" as I would prefer to stick with Kodi, but it will help continue to narrow down the issue.

[VonMagnum]

@Pirivan - That's interesting because before Leia, the issue I would get once in awhile was not a "stop" but instead it would "freeze" momentarily and then eventually "catch up" at high speed like a fast forward after it resumed to the amount of time it was froze (audio would instantly continue at the new point and the video would fast forward to catch up to it).  Krypton only used SMB1 AFAIK so the buffering/slowdown you seem to get might be related to what I was seeing, although it would only happen here at similar intervals to the random stopping (every 30-90 minutes or so give or take).  In fact, because Leia forces on hardware acceleration for AVI files even though it's broke on Android (it apparently had exceptions in Krypton that disabled it for files it didn't work right with), I was forced to turn ALL hardware acceleration off in order to view my older AVI files.  I watched a MP4/M4V and MKV files without reenabling hardware acceleration and I got one of those weird freezes with the catch up/fast forward on them.  That seemed to not happen with hardware acceleration turned on (first time I've seen it in Leia, I think).  But with it off, it's perhaps behaving similar to Krypton again.  There might be a connection in there somewhere between the two behaviors.  With hardware acceleration turned on, MP4/M4V and MKV seem fine on my FireTV with KODI in Leia.  But with the Shield, it seems to happen either way.  I can try forcing SMB1 with the Shield the next time I watch a movie and see what it does.

[Pirivan]

@VonMagnum That sounds pretty similar to ssue I am seeing when forcing the use of SMBv1 with the shares mounted on the shield though not exactly the same; I understand precisely what you are describing though, I have seen that using other playback software on Windows.  It's possible that it IS exactly the same issue, it's just that in Krypton there was no loading/buffering UI so it would pause then do the 'sped up motion' instead of showing a timer while it 'buffered'.  I have not messed at all with disabling hardware acceleration, that is all still set to defaults.

Another update, I tested mrmc (all default settings) with my QNAP set to allow minimum SMB version: smbv1 and max smb version: smbv3.  Playback was perfect, no buffering, no halts/exits.  So, even 'better' results vs. Kodi with shares mounted in Android and forced to smbv1 by the QNAP.  If I could replicate this in Kodi I would be happy, as it allows the Shield/Kodi to choose whatever version of SMB it negotiates AND still allows my Windows machines to connect to the QNAP via SMBv3. 

I also set min/max smb versions on the QNAP to SMBv3, then swapped mrmc over to using libsmb2.  You can do this in the mrmc settings and you HAVE to do that in order to connect to the SMB shares at all with the QNAP only allowing SMBv3, I couldn't connect to the shares at all in mrmc without doing this.  This playback had the same random exit issue as in Kodi when SMBv3 only is allowed.  I am not sure what version of SMB mrmc was using with default settings.  I THINK it uses libsmbclient by default (and you can CHOOSE to use libdsm or libsmb2) and I am guessing that is auto-selecting SMBv1 when the QNAP is set to allow SMB1-3.  So for mrmc as well on the Shield 2015, smbv1 seems to work better than smbv3 (again, making an assumption that is the version that mrmc is selecting with default settings when smbv1 is allowed on the QNAP, no definitive proof that is true).