XBMC4Xbox

This is something I've wanted sorting out or at least explained.

Until quite recently I've just used XBMC4Xbox as an occasional app prefering UnleashX file manager with its built in text editing options. Therefore I stuck with an old version of XBMC (2008) until quite recently when I started updating to the more recent v3 updates.

What I hadn't noticed, and this applies to all the v3 versions I've tested, is that when copying files in the file manager, the Copy status box behaves strangely. It only appears at the start of the copying procedure and then flashes on screen intermittently when a new large file starts to transfer (Texture.xprs for instance). Because there is no indication except those on screen flashes of the status box and the sound of the HDD copying the files that anything is happening it is very easy to accidentally interupt the copying before it is finished.

I thought this might be a skin issue but I've checked and it occurs with Xbox-Classic, Project Mayhem III and Confluence.

If you turn off the dash animations in Skin Settings the Copy status box does remain on screen but only shows any activity when one of those large files starts to transfer.

Whatever this problem is it does not affect the XBMC file manager Move or Delete options status boxes. When used Move and Delete status boxes show all the files being moved or deleted continuously until completed. These two options working as you'd expect also suggests that the issue described is not specific to my set up.

Why does the v3 XBMC4Xbox file manager Copy status box behave like this?

It is a feature to speed up copying of small files. Updating the progress bar slows it down, so when copying many small files, it doesn't constantly update. That's as I remember it anyway.

So it is deliberate, yes? But that then begs the question why was it not also applied to Move and Delete too?

Also why does Move include a progress bar which doesn't actually work? That might be a skin issue (Xbox-Classic) as I didn't think to check that with other skins. I will do that tomorrow.

What a pain these 'helpful' changes can be. It provides a good reason to keep my old 2008 XBMC version as an app or use UnleashX for copying. I don't know about other users but I want to see my stuff is actually copying or at least a visible indication the copying process is proceeding. Ideally, in the case of a failure, immediate access to the event log can also be very useful, which is something you do also get with the UnleashX file manager.

Yeah I just use UnleashX to do heavy file operations, and consider XBMC4Xbox a kind of reliable convenient backup alternative to managing the filesystem

fxmech wrote:Yeah I just use UnleashX to do heavy file operations, and consider XBMC4Xbox a kind of reliable convenient backup alternative to managing the filesystem

yep same here, unleash x or using FTP. xbmc works well to transfer but i prefer unleash x

I'm still not liking the lack of a Status box and progress bar in all recent XBMC4Xbox builds. In fact I could do without the bar as that has never been a reliable indicator as the equivalent UnleashX one. I'm still using a late 2008 XBMC v9.04 build kept installed specifically for copying purposes.

It is the Status box flicking on and off all the time when a new file starts to copy.................it is just so damned annoying and unhelpful. Surely an option for a permanently visible Status box displaying copying details that doesn't affect the functioning of other GUI elements could be provided? I'd be happy to take a copy speed drop.

As for using UnleashX for copying instead that has its own issues and often one connected with XBMC.

UnleashX will not copy text files even when they're on the same drive without them having an appropriate text file extension eg. .nfo, .txt. You can FTP them to one drive OK but try copying from say to another folder on E:\ or to F:\ or G:\ with the UnleashX file explorer and you'll get a failed to copy error message.

The problem is a lot of XBMC4Xbox builds contain various text files like READMEs, particularly in the Python folder, which don't have any of those extensions. They're not the only culprits either, I've just spent ten minutes editing eight such files in an emulator folder that failed to copy multiple times because of text files hidden within sub-folders.

I usually FTP XBMC4Xbox updates to F:\ first, check they work OK before replacing my prime XBMC4Xbox installation on E:\. I'm always coming across this problem and why I prefer to use the XMBC4Xbox file manager for the copying. It doesn't have the same problem (parser?) and so such files are copied without issue.

I'm happy with the way it functions currently.

But it is inconsistent. When you use the Delete option the Status remains on screen and, I think, the same is true for Move.

I've also never seen a file copying/management system on any other device which behaves like this. That suggests there are dozens of designers, and who knows how many actual users, of such GUI's who don't think it is a good idea.

I'm not saying change it I'm simply asking for the old copy Status box (+ progress bar) to be provided as a Settings option. Would it really be that difficult?

It's work I don't want to do. Delete and move are faster operations than copy, but whether you think it's logical or not, it's not something I'm interested in changing.

The problem with Move is that it is risky - just one failed file transfer for whatever reason and both source and target are messed up. Also it is inappropriate for many purposes, like transfering archived skin folders to a new dash version for testing before final install. I want to copy them not move them.

I understand the desire for increased copying speed but not at the expense of the GUI. If people want speed then FTP stuff directly to where you want it and get copious copying and progress information in the process. But for those of us actually using the File Manager for copying stuff around the Xbox, affecting the functionality of the GUI for a few KB/sec more speed just seemed/seems to me like somewhat uneccessary tinkering.

If it concerns you that much, I can only suggest you look into making the changes yourself.

Love to, wish I could but it is a bit beyond me.

I'm criticizing the decision to make the change, in fact not even that, just that it was not made optional. Give people a choice and everyone is kept happy. It should go without saying that the work and the obvious effort put into XBMC4Xbox and all the other stuff done here is of course much appreciated.

Is this not a skin related option?. I seem to remember seeing a skin with the option, "show progress bar".

Coldly-Indifferent wrote: I'm criticizing the decision to make the change, in fact not even that, just that it was not made optional.

This change was made years ago. You are talking about it as if I have recently changed something. I am not interested in spending my time working on this. You are free to learn and work on it yourself though - but going on about it is not going to persuade me.

xman wrote:Is this not a skin related option?. I seem to remember seeing a skin with the option, "show progress bar".

Could be although it may not update despite that as I think that's in the code. It's been years since I looked at this part of XBMC4Xbox so I don't actually remember.

BuZz wrote:

Coldly-Indifferent wrote: I'm criticizing the decision to make the change, in fact not even that, just that it was not made optional.

This change was made years ago. You are talking about it as if I have recently changed something. I am not interested in spending my time working on this. You are free to learn and work on it yourself though - but going on about it is not going to persuade me.

Of course I know now it was made a long time ago and I wasn't bothered about it at the time because I didn't know then. I was using XBMC as an app and I was happy to continue using my old 2008 version. However last year I decided I wanted to set up a Xbox with XBMC as the main dash and when I belatedly discovered this change and, as I use the file manager a lot, I worked my way back through the v3 series hoping that it was some recent introduction.

As I said in my OP it is or was possible to keep the Status box on screen by changing the dash animations settings but this affects other things and was not really what I was looking for. I was hoping there might be have been a fix that somebody had worked on in the mean time which is why I've asked about it here again.

I would have been happy enough just with a dialogue box confirming the copying was proceeding, maybe a small flashing cursor to indicate activity and then, once finished, a confirmation message that it had. I'm not trying badger anyone to provide me with any solution that's just an alternative idea, not a request. But surely something simple like that would have been better and used less resources too.

Yer, it was the PMIII skin that had this feature where it truly worked as designed. PMIIIHD had it as well but it was patchy at best. I don't think Confluence ever had it. I seem to remember talking about removing this feature in the quest for more available RAM. On the current Kodi PC version it is there but has been moved to the top of the filemanager. It displays the folder/file name and a progress bar and it works well. Pity the actual operation of Kodi on the PC is patchy. I suppose the trade off is to use an early version of XBMC4Xbox while doing filemanager transfers. Easy to do, load an early version XBMC4Xbox in your "Favourites" or even set that early version to the filemanager tab and make it the default operation. What this will do is boot the early version whenever you select filemanager automatically. Alternatively, use the Kodi PC version on a PC or Android device where the progress bar does work but then you will loose the fluency and snappy operation of XBMC4Xbox we have all come to expect and learn to put up with the annoying lockups that haunt current Kodi on other platforms. What I have learnt since this feature was dropped is on XBMC4Xbox is when filemanager is still transferring or doing any operation you have selected, the selected files/ folders with be yellow. To check if it is still doing anything click the start button and see if the selected files/ folders go back to white. If they don't, filemanager is still doing work. If they go white, the task is finished. Not a progress bar but.

Interesting tips from Xman to check whether the operation is still going (last part of the previous comment). Another way I used to to check was to try navigating up or down and then hear the bubbles as a confirmation it didn't freeze.

I understand Buzz is not interested in making a change in that area (why possibly break something that you will need to fix again), but had a quick dig around the code to see which part is it and possibly when iit changed and why.

If not wrong I think the logic is in this xbmc/utils/AsyncFileCopy.cpp file, which runs as a tread, does the copy in the background and while doing it it loops around to update the progress bar. It has an initial delay of 1/3s and then apparently another 0.5s delay before it updates the dialog. Therefore when copying a small file the progress bar might not show up at up or it will not be updated. xbmc/utils/AsyncFileCopy.cpp (r1500, 05 Sep 2008). The code was very little changed since it was originally written (history)

It appears it started to be used a little later in 28 Feb 2009 by Arnova as part of a larger change (GUIWindowFileManager.cpp changed to use the async copier as opposed to direct copy and progress update).
http://redmine.exotica.org.uk/projects/ ... ions/18156

Re copy vs move difference in behaviour, when moving to the same drive it will rename it very quickly, but if moving to a different drive it will do a copy and if succesfull followed by a delete. So in a way it does behave the same at least in the second scenario.

Dan Dar3 wrote: but if moving to a different drive it will do a copy and if succesfull followed by a delete. So in a way it does behave the same at least in the second scenario.

Well I just learnt something. I have always copied and then deleted the original folder/ file in preference to just a move solely on the chance the move may fail to function correctly. Seems I was worried about nothing as the machine checks all is correct before deleting the original data.