Posts: 49
Joined: Jan 2008
Reputation:
0
I really wish that one of the developers would take notice of this thread and look into this issue, because it would be a shame to leave this bug in the Dharma release. This obviously affects a lot of people, and it seems to be confirmed that it's NOT just a networking issue.
Posts: 3,805
Joined: Mar 2004
Reputation:
3
elupus
Team-XBMC Developer
Posts: 3,805
It could be skin related if the skin is doing something silly over the network. So test with standard skin.
Also, don't think people have said if they have this issue with Live or not. If it's live, maybe some driver update in linux have caused it.
Would be nice if people with the issue could hook up a 100Mbit switch between the two computers and see if they can repro the issue then.
Posts: 49
Joined: Jan 2008
Reputation:
0
I'm running XBMC on Windows 7, and using Confluence. There's another thread on this topic, and on that thread they were suspecting Windows 7 as the culprit. Can everyone report what OS your using so we can narrow it down?
If I have time tonight I will hook my XBMC machine and my WHS server to a 100 Mbit switch and test to see if it's related to gigabit connections.
Thanks for your suggestions elupus.
Posts: 5
Joined: Jan 2009
Reputation:
0
I have also run into this issue while setting up a 2nd PC with XBMC. Both of my machines are running Win7, XBMC RC1, default skin. My main HTPC has all of my media files, etc. Second PC is accessing that media via hardwired 100Mbps LAN connection, through a DLink Dir-615 router.
I don't believe it is my network that is causing the issue. When doing a file copy from one machine to the other I am getting over 10MB/s transfers. While watching a 1080p MKV in XBMC, my network utilization is only 25% and I get frequent buffering.
I will try running XBMC Live and see how that works.
Posts: 11
Joined: Nov 2010
Reputation:
0
2010-12-01, 11:28
(This post was last modified: 2010-12-01, 11:36 by morgoth67.)
This is what my setup looks like (in case it helps). Bear with me, for it is rather complex. In the beginning I had buffering problems, but they are gone now.
Phase 1: buffering problems
The XBMC machine (ION330 + Ubuntu 10.04 64b + Camelot) connected to PowerLine adapter (Devolo 200Mb), transmitting via electrical wires to the other end of the powerline adapter, which in turn connected to GigaLan Switch, and from here to the PC with the mkvs (running also Ubuntu 10.04 64b and Samba). All cables are gigalan and all network cards in the computers also.
________________________________ Internet
___________________________________||
______________________________Router 100mb/s
___________________________________||
__XBMC === PWL200 = PWL200 === SWTGb === SMB (Ub10.04)
(Ub10.04)__________||______________||=Laptop 1
_______________PWL200____________||= Laptop 2
__________________||______________||= Printer
_________PC for music, nonXBMC
______________(Ub10.04)
With this setup I had the buffering problem constantly in xbmc, but none of the other devices where having network issues. Furthermore, the xbmc machine was detecting the powerline adapter as "non-gigalan" so it established connection at 100mb/s, and thus not taking advantage of the 200mb/s.
Phase 2:no problems
The only thing I changed is connecting a GigaLan Switch between the XBMC machine and the powerline, having everything the same:
_________________________________________||
XBMC ==SWTGb== PWL200 = PWL200 === SWTGb === SMB
_________________________||______________||
With this setup, all problems have disappeared in xbmc, no buffering anymore.
Hope this helps.
Posts: 84
Joined: Mar 2010
Reputation:
0
Thanks Morgoth67,
good to hear that Your problem is gone with that solution. My devices are all connected directly to Gbit switch so there is not option to make changes like You did. Ofcourse adding a slower switch between XBMC-PC and Gbit switch would be a trick to test, but not having a one to test currently.
If I remember right there were similar network problems with NMT C200 players and they were also "cured" by adding a slower switch.
Anyway I think that this should be working also with pure Gbit network.
Br, Zemy
Posts: 67
Joined: Jan 2010
Reputation:
0
Just my .02 on this:
My LAN setup is much more complicated than the above, including multiple 100mb wifi routers (acting as DHCP relays, providing switching and wifi access points functionality), 1x 100mbit and 2x 1gbit switches, 4 XBMC Dedicated machines all on different PC hardware, each usually storing a different set of media files and picking up the rest from the "Sources" (only Music is centralised on a dedicated WinXP PC server), 2 of these are Linux (Dharma B1, B2) & 2 are Win7-32 (both Dharma RC1), 2x Linux-based Technomate satellite receivers (enigma-1 and enigma-2, both 100mbit LAN), and finally a number of Win PCs used by the family.
LAN Performance:
There are no problems or any visible difference whether the playback is from the local HDD, 1gbit LAN segment, 100mbit LAN segment, or going via multiple 100mbit segments (between the total of 3 routers...).
Tested only up to 720p .mkv - I have nothing that has higher bandwidth requirements...
My experience with AC/LAN adapters (no-name) is disastrous. Quality/CRC entirely dependant on the distribution board cabling / plugs config. Not using them any more because it is impossible to predict the performance until tested on specific AC plugs.
Posts: 49
Joined: Jan 2008
Reputation:
0
So, just to summarize, it sounds like there could be multiple, separate, but perhaps related issues here. Some people seem to be able to fix the problem by tweaking their network configuration, but others have had the buffering problem using USB or even internal hard drives. More than one person has indicated that they are using a 100 mbit switch, so it's not just an issue with gigabit. Not everyone is on Windows 7, but it looks like most are using Confluence. I'm going to try the Aeon skin tonight and see if that fixes it for me.
Posts: 49
Joined: Jan 2008
Reputation:
0
Should I submit a ticket for this? It seems pretty well verified as a real bug.