I bought a Raspberry Pi 2 yesterday and installed Rasplex which looks great and could be my favorite Plex client but i'm having issues with the playback stuttering and skipping at random times.
I have read that people have had this issue when using Wifi for the Pi 2 instead of a wired connection.
Can anyone comment to prove/disprove this theory before i go and buy power line adapters to run a wired connection.
I was using a wired Raspberry Pi 2 and I encountered problems as well. I recommend waiting for version 0.6.0 which supports the latest Openolec.
If you have the time you can try installing openolec directly - to see if that solves the issues you got. (ofcause you will not have all the plex features)
I still have an older pi, but I had similar issues since the first day I upgraded to 5.0. I believe it’s a driver issue with my/our WiFi adapters, but It doesn’t bother me enough to buy a new one… Maybe if 6.0 takes much longer
Hi, same here with a wired raspberry pi2.
I have tested all frequencies and always have stuttering
Stuttering when on a wired network usually points to either a problem on the network or you are trying to play content that needs to be transcoded and your server can't keep up.
What do you suggest me then? Always transcode? Really my network is not full wired:link router to raspi is wired but pc(server) to router is Wi-Fi
Forced Transcode without succes! It seems as if a frame is lost or repeated. The problem does not happen with Chromecast using the same tv
What do you suggest me then? Always transcode? Really my network is not full wired:link router to raspi is wired but pc(server) to router is Wi-Fi
You misunderstood KnightOrc's comment. What he meant was that your server may already have been transcoding those stuttering media, but was unable to keep doing that work at sufficient speed to avoid stutters. This happens with a lot of the low-end PCs and NAS servers used for PMS.
Switching settings to always transcode would only worsen that problem.
The only good solution with a low-end server is to re-encode videos to use formats/CODECs that don't need to be transcoded.
But if you know that the videos in question are not of such kinds that would require transcoding, then this is not your problem.
eg: Normal MP4/MKV files with AVC+AAC CODECs do not require transcoding, and neither do normal AVIs with XviD+MP3 CODECs.
As for WiFi issues, it doesn't really matter how full your own LAN is. Unlike Ethernet WiFi is also subject to outside interference, both in the form of other WiFi LANs using the same physical radio channel, and in the form of generic RF interference (microwaves, power drills, almost any electrical equipment performing physical work). And like all radio signals they are also subject to RF shielding that can lower signal levels. (eg: metal wire netting or sheets inside walls)
People often disregard channel collision as a source of interference, simply because the authentication methods make it SEEM as if each WiFi LAN is physically separate, but nothing could be further from the truth. At low level, outside the encryption layer, packets of unrelated LANs using the same physical radio channels collide all the time, and for each such collision only one of the colliding packets (at best) can survive. Frequently all of the colliding packets must be discarded, either with resend requests or with automatic retransmission after response timeouts.
So there's nothing strange about WiFi connections nearly always giving worse streaming results than Ethernet.
The great wonder is that WiFi connections work at all, despite those frequent packet losses.
Best regards: dlanor
You misunderstood KnightOrc's comment. What he meant was that your server may already have been transcoding those stuttering media, but was unable to keep doing that work at sufficient speed to avoid stutters. This happens with a lot of the low-end PCs and NAS servers used for PMS.
Switching settings to always transcode would only worsen that problem.
The only good solution with a low-end server is to re-encode videos to use formats/CODECs that don't need to be transcoded.
But if you know that the videos in question are not of such kinds that would require transcoding, then this is not your problem.
eg: Normal MP4/MKV files with AVC+AAC CODECs do not require transcoding, and neither do normal AVIs with XviD+MP3 CODECs.
As for WiFi issues, it doesn't really matter how full your own LAN is. Unlike Ethernet WiFi is also subject to outside interference, both in the form of other WiFi LANs using the same physical radio channel, and in the form of generic RF interference (microwaves, power drills, almost any electrical equipment performing physical work). And like all radio signals they are also subject to RF shielding that can lower signal levels. (eg: metal wire netting or sheets inside walls)
People often disregard channel collision as a source of interference, simply because the authentication methods make it SEEM as if each WiFi LAN is physically separate, but nothing could be further from the truth. At low level, outside the encryption layer, packets of unrelated LANs using the same physical radio channels collide all the time, and for each such collision only one of the colliding packets (at best) can survive. Frequently all of the colliding packets must be discarded, either with resend requests or with automatic retransmission after response timeouts.
So there's nothing strange about WiFi connections nearly always giving worse streaming results than Ethernet.
The great wonder is that WiFi connections work at all, despite those frequent packet losses.
Best regards: dlanor
