RPi 2 random stutter over LAN

i want to ask some… what codec use this file ? Xvid ? x264 ? or ? You can give some mediainfo ?
I have notify the x264 if the profile it’s higher of “HIGH@L3.1” i obtain some struttering image on my Pi2 whereas with mail@l3.0 or lower profile i never obtained problems and usually i use samba (PC-Windows <-> Pi2 by LAN and 2 routers) and all file it’s about 2GB of size.

Every 2 or 3 days… i also can suggest to you to reset your routers. i thinks this can help you to resolve some problems…

For example, I recently obtain the same exact problems only whit a specific XVID files:
Video continue to struttering and it’s unwatchable… i compare the mediainfo of this whit all my other xvid file and apparently all it’s ok (no packed bitstream or similar).

I mostly got high profile x264 mkv’s … they all run without problems, even high bitrate bluray rips run without a problem.
But indeed … i’m interested in the mediainfo of his files as well :wink:

If you need to reset your network equipment, you need to buy better stuff … i’ve had one time a problem, related to a router and replacing that one solved all the problems it caused.

I don’t really need to reset but but I do it anyway… tipically every one or two week. :slightly_smiling:

Ok… check the mediainfo of this mkv… before to buy this my Pi2 i have a WD standalone players and the x264 whit profile High@L4.x not working (and it’s also indicated in the manual) for a hardware limitation.

Now on Pi2 sometime i have found some x264 whit Main@L4.0 and it’s working… i never found a file whit an higher profile over “the world of internet” :wink:

Running silky smooth, cpu not even above 10% usage …

Unique ID : 251373940480041184065839076800297602043 (0xBD1CDC23C6E4C94787EFC063C9668BFB)
Complete name : blablabla.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 10.9 GiB
Duration : 2h 21mn
Overall bit rate : 11.0 Mbps
Encoded date : UTC 2015-12-29 20:19:25
Writing application : mkvmerge v8.5.2 (‘DiAMOND’) 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Duration : 2h 21mn
Bit rate : 9 543 Kbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40: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.259
Stream size : 9.21 GiB (84%)
Writing library : x264 core 148 r2638 7599210
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / 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=24 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / 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=50 / rc=2pass / mbtree=1 / bitrate=9543 / 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

ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 2h 21mn
Bit rate mode : Constant
Bit rate : 1 509 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 1.49 GiB (14%)
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
Default : Yes
Forced : Yes

Text #2
ID : 4
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Default : No
Forced : No

Text #3
ID : 5
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : sdh
Default : No
Forced : No

00:00:00.000 : en:00:00:00.000
00:03:22.285 : en:00:03:22.285
00:10:08.983 : en:00:10:08.983
00:15:24.590 : en:00:15:24.590
00:18:25.187 : en:00:18:25.187
00:21:34.376 : en:00:21:34.376
00:24:28.092 : en:00:24:28.092
00:28:52.689 : en:00:28:52.689
00:31:36.645 : en:00:31:36.645
00:34:21.101 : en:00:34:21.101
00:39:13.434 : en:00:39:13.434
00:41:21.771 : en:00:41:21.771
00:46:23.531 : en:00:46:23.531
00:49:25.087 : en:00:49:25.087
00:56:15.747 : en:00:56:15.747
00:59:40.494 : en:00:59:40.494
01:02:23.823 : en:01:02:23.823
01:06:53.134 : en:01:06:53.134
01:09:52.980 : en:01:09:52.980
01:13:51.302 : en:01:13:51.302
01:18:38.255 : en:01:18:38.255
01:22:52.467 : en:01:22:52.467
01:30:41.269 : en:01:30:41.269
01:37:30.094 : en:01:37:30.094
01:43:31.997 : en:01:43:31.997
01:46:16.287 : en:01:46:16.287
01:50:18.737 : en:01:50:18.737
01:54:07.966 : en:01:54:07.966
01:57:49.312 : en:01:57:49.312
02:04:41.683 : en:02:04:41.683
02:11:05.733 : en:02:11:05.733
02:13:28.792 : en:02:13:28.792[/code]

Exactly… on my previous WD Standalone this file would not be reproducible.

I never tryed this profile on my Pi2… when i need to encode some file myself i ever used the HIGH@L3.1 (many many user this profile) and i thinks it’s best choice for maintain the best compatibility also on “old” hardware standalone players…

Otherwise… WOOOOW 10.000 for average bitrate… lol all file i ever watched on my Pi2 use bitrate loss to 2000 :slight_smile: and size lower than 2GB :slight_smile:

Believe me … your RPi 2 can handle almost everything :wink:

yeah… i thinks also but some PEOPLE don’t know this limitation and use not compatible profile :wink:

Every time everywhere… somewhere can see piracy content speak about inside this thread @Theetjuh you can confirm your file it’s your personal rips…

I was just posting an example of a file that works perfectly on my RPi2, no idea what others where doing or intending though :neutral_face:

The MOD says we can speak about all…

Just throwing in my 2 cents worth. Been having stuttering/choppy playback the last couple of weeks. My benchmark video(specs below) used to play fine, but was also choppy. My resolution was enabling OMXPlayer hardware acceleration, and adding the following to my advancedsettings.xml


Video Specs

Format : Matroska
Format version : Version 2
File size : 9.83 GiB
Duration : 2h 15mn
Overall bit rate : 10.4 Mbps

Turned my RPI2 on yesterday, OSMC said there was an update.
I installed latest update.

Stuttering has gotten worse now. I haven’t changed anything.

Previously everything was working fine on SMB access.
Was told to move to NFS… OK did that. Stuttering left.

Now I’ve just updated and NFS now stutters even worse than before.

I’m convinced now that these updates are screwing up the networking somehow.

You’ll have to provide logs to prove that…

Will do … fair enough.

Just adding that last time, that’s what you had me do.
The outcome was: “Don’t use SMB, use NFS”.
However before those previous updates, smb was working fine. Now NFS doesnt behave since last update … My setup hasn’t changed, only difference is the update.

If you are using the Kodi build in NFS drivers you might wanna try moving to the kernel drivers (mount via fstab).
Check this thread Consistently interrupted playback - #23 by THEM

I have stuttering with OSMC even when played from USB. It doesn’t seem to be related to the refresh rate etc. I’m using the same RPi2 with the same type of SD with a fresh OSMC and a fresh OpenELEC install. OSMC has random stutters and OpenELEC does not. I will post two logs (one from OSMC and one from OpenELEC) playing the same file in the next days to hopefully find out why that is. Should I activate something special while logging or is the normal debug log enough?

Depends on the type of stutter.
It can be cpu, bandwidth or timestamp related.

cpu related will likely show at least one core close to 100% utilisation (you can see this in debug codec overlay - ‘o’ key). You will probably see “skip:” and/or “drop:” numbers continually increasing.

bandwidth related means we can’t read the data fast enough. More likely with slow networks (e.g. wifi). You will see lower cpu, but dropping video/audio queues. These are the “vq:” and “aq:” numbers in codec overlay which ideally should be close to 100%. If they drop to zero you will get buffering.

If it’s neither of these then it’s probably timestamp related. We have received data and decoded it in time, but just didn’t display it nicely synced with vsync. Make sure “adjust display rate to match video” and “sync playback to display” are both enabled for smoothest video. Might be worth trying with omxplayer enabled/disabled as the logic for exactly when to display frames is a little different. It may be the file is poorly encoded and just has too much jitter on the timestamps. This often occurs when video has been converted between different framerates.

If it is timestamp related, then providing a sample video that shows the problem is the best option. Check that is can play smoothly on a different media player. The logging doesn’t have enough detail to diagnose these, but it may be solvable with a specific example to work on.

1 Like

I switched from OpenELEC 6.0.3 to the latest OSMC release on my RPi2 and just wanted to say that I also noticed stutter from time to time. No stutter on OpenELEC. I’m using MMAL hardware acceleration with media stored on USB HDD, Sync Playback to Display enabled with Adjust PLL. Can’t get rid of the intermittent stutter.

I use my Pi primarily for live TV but I’ve found that adjust to display set to on/off and sync to display set to off work for me. With sync to display on I get shuddering playback. Try it yourself and see if it helps.

It’s not related to that. As we said it runs fine using OpenELEC with any settings and doesn’t when using OSMC.
We have now two topics about this issue. Here is the other one: MMAL Skipped frame or judder every few seconds - #6 by kartana