today I discovered that Rasplex cannot even stream a simple mp3 music file.
I get in the bottom left corner a little message box that shortly says unknown video codec.
This has to get fixed otherwise you can't even play music over Rasplex.
I think I am using the last stable version 0.4 (I will upate to rc3 now and check again)
Unfortunately you did not search the forums before posting.
This thread is for RC3 issues/observations and you're not even on RC3 yet, as you will no doubt discover this has been fixed.
I'm finding that a few 1080i mpg2 files I have that have been recorded from TV are not being correctly identified as interlaced, and are hence displaying with visible combing...
Any thoughts?
I'm on rc3.
Also, large wtv files still will not play on my system, but I believe this is a xbmc issue more generally. Small ones work fine.
1080p playback. It freezes about 2 or 3 times for the first 15 seconds, then it plays fine. I think the picture is not as sharp sometimes as in 3.x. But I might be wrong about that. I'm on a Gb wired network with direct play. Bit rates I don't know coz when I click properties of the file, it shows bit rate N/A.
- Photos slide show. Pan and Zoom is not smooth. It stops every second or so.
- Viewing online content. I have my PI set for a resolution at 1920 x 1080. Online playback set at 1080 as well. Content is 480p or SD and then is played not full screen but windowed. if I change internet playback settings into "Always ask" No change. On SD settings it's full screen but terrible quality. Edit: Actually this is only on one of my PI's, so nothing to do with RC3 but with some settings. Disregard this.
- Update progress works smooth and a very usable progress bar.
RC3, for me personally, is acceptable, keep up doing this great work. Thanks.
I have issues with the sound dropping about every other minute for like 3/10 of a second. Haven't had this problem before (tried earlier betas and RC1). Sample file: http://bit.ly/1kl6PGW
Not sure if the sample is long enough to test the problem since it might be several minutes between the hiccups.
This seems extremely related to my posted bug here, please take a look at it. There's also a possible soultion in that thread. Maybe you can try it too? https://github.com/RasPlex/RasPlex/issues/222
By the way, i'm having exactly the same issue on every Rasplex version I tested so far: https://github.com/RasPlex/RasPlex/issues/67 Issue is closed and apparently fixed in 9.9.15, but thats not the case for me...
No report on playback stutters is complete without mention of which media are affected. By this I mean both CODECs and bitrate. Resolution seems to be the only thing some people report, like 720p or 1080p. But compared to the overall bitrate and the CODEC choice the resolution is of secondary importance.
And if your problems really extend to ALL media, regardless of how low the bitrate is, then that too needs to be reported.
Without knowing sufficient details of a problem it's impossible to analyze, and thus impossible to fix.
Well I can check more files to see the lowest bitrate that is affected, but just first example from yesterday night: Bitrate 2773 kbps, Codec H264, Direct play, WiFi. Playback wil stutter for as long as the cache is filling. Most (or all) SD files play smoothly with no stutter.
2773 kbps is not a problem for an Ethernet connection, but for WiFi it depends on several different factors which VERY frequently ruin WiFi results. These factors include inefficient use of USB WiFi dongles as well as high risk of data packet collision with surrounding WiFi networks.
People often mistakenly consider WiFi as a direct connection from one unit to another, partly because the encryption makes it appear as a closed connection, not interacting with other nearby networks. But that is a false impression. The encryption only prevents intrusion and interaction on the level of logical data transfers.
But there is always a STRONG physical interaction between networks near each other and using the same base frequency. Every time two such networks send data simultaneously there will be a packet collision, frequently resulting in corruption of either one or both of the packets involved. Any destroyed packets will have to be resent from the point of origin, but that will only happen after additional requests and/or timeouts. And with several nearby networks using the same frequencies (often the default setting of a standard router), this kind of collision can go on in a truly chaotic way, with resend requests and responses consuming a major part of the available bandwidth.
If at all possible you should try the same media with a wired Ethernet connection, to see if it truly is the playback method or the network transfer method that is causing the problems.
There are only 2 networks nearby (at least that are broadcasting ssid), both of which use channel 11, whereas I'm using channel 6, I also replaced antennas on my router and raspberry wifi card, right now signal strenght is at ~60%, which is rather disappointing, considering that any laptop, tablet or smartphone that is being used at the same location has considerably stronger signal strenght.
Anyways, someone had this problem and it went away with software update, so just saying...
There are only 2 networks nearby (at least that are broadcasting ssid), both of which use channel 11, whereas I'm using channel 6,
Good. That should rule out packet collision, assuming of course that your RPi and the PMS server are the only ones using your WLan at the times when your problems appear (else they have to share bandwidth with other units on your LAN).
But that still leaves the possibility of the WiFi dongle access being less effective than the internal Ethernet port, as well as the probability that WiFi transfers may suffer packet loss for other reasons. (Signal strength, other electrical signals with static bursts in the same frequency band etc.)
I also replaced antennas on my router and raspberry wifi card, right now signal strenght is at ~60%, which is rather disappointing, considering that any laptop, tablet or smartphone that is being used at the same location has considerably stronger signal strenght.
Anyways, someone had this problem and it went away with software update, so just saying...
It is very possible that some future software update will improve your results, as there is work going on even now to reduce risk of stutters even at much higher bitrates than you used in your testing. But I still think that your present problems would go away, or at least be considerably reduced, if you used wired Ethernet connection instead of WiFi. I strongly recommend trying it.
I'm still getting (although it did stop for a few versions then suddenly reappeared) the issue where the audio drops out and then the playback freezes a few seconds later. On previous versions it was impossible to ssh into the Pi (as the entire thing had crashed) but it's now possible when this happens to ssh in and reboot it nicely. Mashing buttons on the remote does nothing.
Happens on both 480p and 720p, avi(xvid), mp4 (x264) and mkv(x264) files. No pattern that I've been able to discern. Some files play all the way through without an issue. Sometimes the issue occurs multiple times in the one file. It doesn't matter if the Pi has just been rebooted. Sometimes it happens just minutes into the file, others it happens towards the end.
It wasn't happening on the 9.9.x builds, but appeared with rc-1 and has continued through all rcs so far. Running latest PMS (non-plexpass) on Ubuntu Server 14.04 (but happened on 13.10 as well).
No overclocking and they're all direct play. Happens on both direct ethernet and ethernet-over-power. (We have two Pi boxes both running rc-3.)
Was using the Pi with RC-3 for about 2 weeks and was excited how well it worked with all my content, including mostly 1080P MKV's Bluray rips. Then all of a sudden it just started stalling and buffering on everything I throw at it!?
Nothing on my setup changed I tried switching from force transcoding at 20MBps to DirectPlay but get the same results.
I am hardwired to the same GigE switch as my MacMini PMS (See signature!)
I was really hoping to use the Pi and move the Mini to a different location (still hard wired to GigE switch of course) but not if it is this erratic.
I'll wait for the next RC release and see if that makes it more stable.
Was using the Pi with RC-3 for about 2 weeks and was excited how well it worked with all my content, including mostly 1080P MKV's Bluray rips. Then all of a sudden it just started stalling and buffering on everything I throw at it!? Nothing on my setup changed I tried switching from force transcoding at 20MBps to DirectPlay but get the same results. I am hardwired to the same GigE switch as my MacMini PMS (See signature!) I was really hoping to use the Pi and move the Mini to a different location (still hard wired to GigE switch of course) but not if it is this erratic. I'll wait for the next RC release and see if that makes it more stable.
If your problems were due to some generic instability of the RC3 release, then they would not have taken 2 weeks to show themselves.
Something must have changed to make that happen, either in your network environment, your PMS server, or in the RPi hardware/storage.
One possibility that comes to mind is that of SDcard corruption.
Maybe I'm to stupid, but i can't enter an IP Adress, not in the Network Connection Settings and also not when I try to set a Media-Server manually. The numbers are no problem, but i can't hit the OK button, the cursor won't got there no matter what I try.
This is not a RC3 problem, I also had it with RC2. I tried it on a Panasonic Viera TV with HDMI CEC Remote, on a Samsung TV (also HDMI CEC) and with the plex App on my Tablet - I had no chance to hit OK.
Also I found out that many keys on the Panasonic Remote are not used which are used on the Samsung Remote, but this is no problem so far.
Keep up the Great work! It's almost perfect now! When 0.40 RC1 came out I sold my Roku 3, because rasplex is much better!
