As I said before, I believe this is a problem with your router.
It happens with both my Edimax Nano WiFi adapter, and with Ethernet.
My router is the latest version Apple AirPort Extreme, with latest firmware, and with no special configuration on it - should work with a standard router like that, no?
Just wanted to chime in and let you know I'm experiencing the same network speed issue where the latest build is bringing my network to its knees. I have a wired setup and it plugs into my Airport Extreme router (which is plugged into a Motorola Surfboard modem). I hadn't experienced any problems up until today when I decided to re-image on a faster SD card. Interestingly, the network becomes super slow when connected to the Pi even when I'm not playing anything on Plex.
EDIT: In thinking this issue might be related to configuration changes I made, I just started from a fresh image and made no changes to the default settings and, once again, my network came to a crawl without playing anything. It seems if its simply turned on, it sucks the life out of the network. I'm going to boot up from a fresh Xbian image next and see if I experience the same problem in case something is wrong with the Pi itself.
First up - AWESOME JOB to Dale and the team to RasPLEX !!!! Finally - my Rasp-PI Model B gets dusted off and appears to work well as a Client.
I started with 0.1.15 last week - and that seemed to work just fine !
Today I re-imaged the card with 0.1.19 - and I noticed an odd problem with what appeared to be a "network broadcast storm" when the default IP settings are in the client config.
Here is what I did)
Imaged CF card with 0.1.19
Booted into RasPLEX menu - and using Preferences, RasPLEX settings - I configured my WiFi settings to use:-
Network Technology = WLAN
Network Interface = wlan0
{I also configured my WLAN SSID / WLAN Security)
(Initially - I left the IP address to the default which I believe is 0.0.0.0 (DHCP assign?)
and re-booted the PI........
When the PI came back up - the menu seemed slow and unresponsive - but more noticeably - my other WiFi devices started to drop connections to the AP / Router; The EdiMax WiFi NANO was "thrashing" - which led me to believe something bad was happening on the WLAN network.
Once the PI was powered down - the other devices suddenly re-connected - and normal WiFi service was resumed.
BOOT 2
Now I booted back up - and configured a STATIC IP / GATEWAY / DNS Server 1 on the Preferences // RasPLEX Settings // Network
Again - reboot the PI - and now all seems OK.
So, IF you are seeing super SLOW network - have you set a STATIC IP address for the Rasp-PI? Try it - and report back......
Noticed the same packet problem when I installed today. Ran up wire shark and the PI was spewing out loads of this:
No. Time Source Destination Protocol Length Info
93548 161.358719000 192.168.1.163 239.0.0.250 UDP 63 Source port: 56496 Destination port: 32414
Frame 93548: 63 bytes on wire (504 bits), 63 bytes captured (504 bits) on interface 0
Interface id: 0
WTAP_ENCAP: 1
Arrival Time: Mar 4, 2013 12:21:52.523157000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1362399712.523157000 seconds
[Time delta from previous captured frame: 0.001286000 seconds]
[Time delta from previous displayed frame: 0.002583000 seconds]
[Time since reference or first frame: 161.358719000 seconds]
Frame Number: 93548
Frame Length: 63 bytes (504 bits)
Capture Length: 63 bytes (504 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:udp:data]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Raspberr_f9:0e:a8 (b8:27:eb:f9:0e:a8), Dst: IPv4mcast_00:00:fa (01:00:5e:00:00:fa)
Destination: IPv4mcast_00:00:fa (01:00:5e:00:00:fa)
Address: IPv4mcast_00:00:fa (01:00:5e:00:00:fa)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Raspberr_f9:0e:a8 (b8:27:eb:f9:0e:a8)
Address: Raspberr_f9:0e:a8 (b8:27:eb:f9:0e:a8)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.1.163 (192.168.1.163), Dst: 239.0.0.250 (239.0.0.250)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 49
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 1
Protocol: UDP (17)
Header checksum: 0xc776 [correct]
[Good: True]
[Bad: False]
Source: 192.168.1.163 (192.168.1.163)
Destination: 239.0.0.250 (239.0.0.250)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 56496 (56496), Dst Port: 32414 (32414)
Source port: 56496 (56496)
Destination port: 32414 (32414)
Length: 29
Checksum: 0x7be0 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Data (21 bytes)
0000 4d 2d 53 45 41 52 43 48 20 2a 20 48 54 54 50 2f M-SEARCH * HTTP/
0010 31 2e 31 0d 0a 1.1..
Data: 4d2d534541524348202a20485454502f312e310d0a
[Length: 21]
Once I configured it with a static IP address and gave it a reboot problem stopped.
Noticed the same packet problem when I installed today. Ran up wire shark and the PI was spewing out loads of this:
No. Time Source Destination Protocol Length Info 93548 161.358719000 192.168.1.163 239.0.0.250 UDP 63 Source port: 56496 Destination port: 32414 Frame 93548: 63 bytes on wire (504 bits), 63 bytes captured (504 bits) on interface 0 Interface id: 0 WTAP_ENCAP: 1 Arrival Time: Mar 4, 2013 12:21:52.523157000 GMT Standard Time [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1362399712.523157000 seconds [Time delta from previous captured frame: 0.001286000 seconds] [Time delta from previous displayed frame: 0.002583000 seconds] [Time since reference or first frame: 161.358719000 seconds] Frame Number: 93548 Frame Length: 63 bytes (504 bits) Capture Length: 63 bytes (504 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ip:udp:data] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Raspberr_f9:0e:a8 (b8:27:eb:f9:0e:a8), Dst: IPv4mcast_00:00:fa (01:00:5e:00:00:fa) Destination: IPv4mcast_00:00:fa (01:00:5e:00:00:fa) Address: IPv4mcast_00:00:fa (01:00:5e:00:00:fa) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: Raspberr_f9:0e:a8 (b8:27:eb:f9:0e:a8) Address: Raspberr_f9:0e:a8 (b8:27:eb:f9:0e:a8) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IP (0x0800) Internet Protocol Version 4, Src: 192.168.1.163 (192.168.1.163), Dst: 239.0.0.250 (239.0.0.250) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 49 Identification: 0x0000 (0) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 1 Protocol: UDP (17) Header checksum: 0xc776 [correct] [Good: True] [Bad: False] Source: 192.168.1.163 (192.168.1.163) Destination: 239.0.0.250 (239.0.0.250) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] User Datagram Protocol, Src Port: 56496 (56496), Dst Port: 32414 (32414) Source port: 56496 (56496) Destination port: 32414 (32414) Length: 29 Checksum: 0x7be0 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Data (21 bytes) 0000 4d 2d 53 45 41 52 43 48 20 2a 20 48 54 54 50 2f M-SEARCH * HTTP/ 0010 31 2e 31 0d 0a 1.1.. Data: 4d2d534541524348202a20485454502f312e310d0a [Length: 21]Once I configured it with a static IP address and gave it a reboot problem stopped.
I noticed the same problem, will look at the static ip and see if it fixes this issue.
Awesome, going to give the Static IP a try later.
Just wondering though, I'm trying to use disk utility to put the img file onto my SD card. Everytime it fails and comes back with 'Could not validate source - Invalid Argument'
Anyone had any similar and know what's causing this? Happens with 16,17,18 and 19. If I run it via terminal it works but then for some reason after first couple of boots on pi, all of a sudden it can't find the system folder and halts the boot.
Really not sure what's going on. Just re-flashing the SD card again.
I just tried with a static IP and it still slows my network to a crawl :(
I think we can start to assume this needs to be fixed in Rasplex and not in the users routers.
Did you assign a static address from Rasplex or give it a static mapped address (DHCP) via your router? I don't think this has anything to do with routers. I use Sophos UTM 9 on a virtual machine as my router and the comprehensive logs show nothing out of the ordinary.
Did you assign a static address from Rasplex or give it a static mapped address (DHCP) via your router? I don't think this has anything to do with routers. I use Sophos UTM 9 on a virtual machine as my router and the comprehensive logs show nothing out of the ordinary.
I gave it a static IP in the Rasplex settings and rebooted. Didn't help unfortunately.
Okay,
One hint maybe. one of the things which would make UDP flood is bonjour bouncing.
Can they guys having this UDP issue try to desactivate bonjour and see if they still experiment the issue and then report :)
Thanks.
Okay,
One hint maybe. one of the things which would make UDP flood is bonjour bouncing.
Can they guys having this UDP issue try to desactivate bonjour and see if they still experiment the issue and then report :)
Thanks.
Thanks for the reply - Where should we disable bonjour?
This is in PMS settings .> network discovery (last option), then you have a checkbox there.
There is no setting in PHT, but might be an issue with it and bouncing UDP requests.
This is in PMS settings .> network discovery (last option), then you have a checkbox there.
There is no setting in PHT, but might be an issue with it and bouncing UDP requests.
I tried disabling bonjour in PMS settings, but rasplex still 'kills' my network, so it's unusable at the moment, sadly.
Hi!
My Rasplex freezes after a few seconds. Around the time it connects/communicates with my receiver (see picture). I have tried v1.19 and 1.17. Same problem.
Before it freezes it is responsive to keyboard input, and it connects to Plex server (I see the Plex server name at the top of the screen)
I do not think it is a HW problem between receiver and RPi because OpenElec and RaspBMC works.
RPi is connected to receiver with HDMI, and is on a wired network.
Any suggestions how to fix this?
thanks,
ole h.
Maybe you can get us some info by checking the logfile and se if you can see any errors.
Logfile should be located in /storage/.plexht/temp.plexhometheater.log
Evening everyone !
We'd need some volunteers to try a new test release (rc20) on which we are having various behaviours. Works fine on some of us, and not very well on some others.
Right now we have too few testers to makesconclusions out of what we see, so if you feel like helping that would be awesome ;)
The new release candidate can be downloaded here https://dl.dropbox.com/u/9175439/rasplex-0.1.20.img.zip
Beware that on some of us, this release has broken playback, so that might happen and you might wanna revert to previous versions if this is the case.
Any of you trying this one and reporting here if he has (or not) any broken playback issue will help.
Thanks guys !
Evening everyone !
We'd need some volunteers to try a new test release (rc20) on which we are having various behaviours. Works fine on some of us, and not very well on some others.
Right now we have too few testers to makesconclusions out of what we see, so if you feel like helping that would be awesome ;)
The new release candidate can be downloaded here https://dl.dropbox.com/u/9175439/rasplex-0.1.20.img.zip
Beware that on some of us, this release has broken playback, so that might happen and you might wanna revert to previous versions if this is the case.
Any of you trying this one and reporting here if he has (or not) any broken playback issue will help.
Thanks guys !
This is very important. 0.1.20 has major GUI improvements, but the playback issue is what is holding it back.
We need to know if lots are having this issue, or just I am.
-Dale
This is very important. 0.1.20 has major GUI improvements, but the playback issue is what is holding it back.
We need to know if lots are having this issue, or just I am.-Dale
Testing tonight when I get home!
Maybe you can get us some info by checking the logfile and se if you can see any errors.
Logfile should be located in /storage/.plexht/temp.plexhometheater.log
Thanks for the reply. I have the same problem with rc20 (rasplex/rpi freezes). I am not able to ftp the RPi, and when I put the SD card in my win-PC I don't see the folder 'storage'. I don't know how to get hold of the log-file.
ole h
ftp wont work .. you need to use SSH.
Then when you connect use plexuser/rasplex as user/password.
once in there you can got into the storage directory and look for the logfile in the path i mentionned.
if you wanna ftp, you need to use sftp, it will work with the same user/pwd.
