Scanning New Media is GOD AWFUL SLOW!!!
#1
Okay, so here is the story. I do not have Internet but I do have all of the .nfo files fanart and stuff for my movies and series. I have 24 television series and when I try to scan them into XBMC it takes about 10 minutes on each episode. Please Note: This computer is offline & not connected to the NET but that should not matter anyways since I already have the NFO files. This is a HUGE bug in my opinion. So far it has been scanning for over 48 hours and is not even halfway done w/my TV series. I pray to god when it hits my movie files (which are a little over 2,000!!!) Does anybody know why XBMC is trippy in this way? Windows Media Center doesnt' seem to have this deficiency. Please help. I will be by the Internet @ school for only about twenty more minutes.
Reply
#2
debug log...
Reply
#3
Well it seems the problem is that is trying to reach the TVDB server (even though local NFO files exist.) It has to wait for a TIMEOUT to theTVDB to occur. After the timeout occurs then it will finally look for the local NFO file. That is what the debug log is telling me. However shouldn't it look for the local nfo file before looking for the server?? Also, I was thinking is there a way to change the server TIMEOUT value to 1 (i.e. 1ms) that way at least the timeout would happen instantly? Right now the timeout is just horribly long and over extended. I have tried looking in the metatdata folder of the TVDB. However, it seems that the creator did not put in a timeout value, which would lead me to believe that perhaps the timeout values are hardcoded within XBMC. If so, that would be something to maybe let the user control ~ or at least give one the option to set their own timeout values. If you still need the debug log, I can put it on pastebin - however, it will tell you the same as what I have done. Thank you for your help.
Reply
#4
Here's a taste of whats going on:

Code:
13:50:32 T:2684 M:522108928 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522108928   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522059776 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522059776   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522534912 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522534912   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522539008 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522539008   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522690560 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522690560   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522747904 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522747904   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522715136 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522715136   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522719232 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522719232   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522723328 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522723328   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522731520 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522731520   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522715136 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522715136   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
13:50:32 T:2684 M:522719232 WARNING: XFILE::CFileCurl::CReadState::FillBuffer: curl failed with code 6
13:50:32 T:2684 M:522715136   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
Reply
#5
firefoxtamer2 Wrote:Okay, so here is the story........ This is a HUGE bug in my opinion.


XBMC depends HEAVILY on online content and it is used almost exclusively.

At best its a minor annoyance and low priority for development. You might be one of a select few who have this problem. XBMC works as it should if you simply plug in the Ethernet cable.

File the bug report, plug it in and move on for now.
Reply
#6
FishOil Wrote:XBMC depends HEAVILY on online content and it is used almost exclusively.

At best its a minor annoyance and low priority for development. You might be one of a select few who have this problem. XBMC works as it should if you simply plug in the Ethernet cable.

File the bug report, plug it in and move on for now.

Yes, I will file the bug report for sure. However, as a developer & programmer myself ~ I don't think making a program work online/offline should ever be considered a low-priority. As for plugging in an ethernet cable, that is kind of a step #1. However, if the user does not have an active Internet connection but still has the incorperated data to their files - then there should be no problem anyhow (or @ least with a well designed and programmed application.) Anyways, with that aside I will take the source code which is readily available and create my own bug fix, I am sure it will be something easily fixable within the internal programming, an obvious bug. However, just wanted to bring this crippling defeciancy to the public attention & see if anybody else has had the same problem, and if there was a resolution to this error. And FYI (48 and scanned only 72 files is more than a minor annoyance, and am sure that anyone would agree to that as well.) But no complaints, XBMC is free so we can't really expect them to have the funds to hire world-class programmers or developers, they do a great job with what they have. Big Grin
Reply
#7
How about a full debug log to pastebin?
42.7% of all statistics are made up on the spot

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#8
firefoxtamer2 Wrote:But no complaints, XBMC is free so we can't really expect them to have the funds to hire world-class programmers or developers, they do a great job with what they have. Big Grin

World's most backhanded compliment! Agreed with tslayer, debug logs posted to pastebin are good. Devs will often be much better at figuring out a problem if they can see what the problem is.
Reply
#9
I have a similar problem.

I add maybe 3-4 television shows a couple of times a week and have the library set to scan at startup.

It takes a good 5 minutes to find and add these episodes even though I have scanned them myself beforehand with ember media manager to get the thumbnail, nfo etc.

The machine is connected to the internet so I don't know what the problem could be.
Reply
#10
Read the thread for goodness sake - DEBUG log would help.
Reply
#11
I saw this problem when my internet died for a day. I just unchecked the option to get actor thumbs and then everything worked fine, it stopped trying to go online.
Reply
#12
I'm glad it's not just me. On my HTPC scanning is normal, on my Mac however, scanning is terribly slow. I'm using XBMC for over 3 years now. And I can tell that this is not normal.

Running latest Eden atm. (Did not have this issue with Darma btw.)

Here is my log file: http://pastebin.com/fKudRRbk
Platforms: macOS - iOS - OSMC
co-author: Red Bull TV add-on
Reply

Logout Mark Read Team Forum Stats Members Help
Scanning New Media is GOD AWFUL SLOW!!!0