Print

[node21]

this should work fine...

But I think you are confusing the CONTENT_BIN_PATH with defining directories.

CONTENT_BIN_PATH is a singleton, and tells the server on which of the other paths you want to store the "content.bin" file.  There's no reason you'd ever need more than one...

Go ahead and define a single Hdd1: and a single Usb0: on the server, and every one of your 360s will be able to put content on the server in those two volumes.

[tstein]

Does the content that I want sync have to first be shown on screen?  IE if I want DLC to sync, must I first do 'Show DLC" and then hit the Both button to sync?

I think my assumption was that if I click both right after xm360 loaded, it would sync ALL content, but the results were just the XBLA

I follow you on the CONTENT_ specifier.

Thanks node

[node21]

all of the sync buttons pay attention to what is currently displayed.

So, if you are on the first screen, and you use RB to show only GOD containers, and sync...only GODs will sync.

If you are on the DLC scene and have chosen to see DLC for Forza, and sync...only Forza DLC will sync.

If you want to sync *everything* you will have to visit the first scene (and leave it on "all"), the DLC scene (and leave it on "all"), etc...

-node21

[xboxhaxorz]

was that restarting issue ever fixed???

[schoenof]

Hi node21...

Any chance you could just always write the report files everytime the content.bin is updated?
I always wondered why this was not just automated...It would save some steps that I do very frequently...and would make my next request unnecessary...

if no on earlier request, any chance we could get a custom FTP command to make XM360 on XB write the report files?  My computer is a long way from my TV and I always am walking back and forth just to tell XM360 to write updated reports...then walking back to computer to FTP the reports and look at them (IMG:style_emoticons/default/smile.gif)  

keep up the good work (IMG:style_emoticons/default/smile.gif) donation sent

schoenof

[node21]

QUOTE(xboxhaxorz @ Sep 25 2010, 07:54 PM)

was that restarting issue ever fixed???

The one where you connect one 360 to another?  I fixed it, but haven't built an official release yet.  I'll do that right now, and send it out to the testers.

QUOTE(schoenof @ Sep 26 2010, 02:47 AM)

Any chance you could just always write the report files everytime the content.bin is updated?
I always wondered why this was not just automated...It would save some steps that I do very frequently...and would make my next request unnecessary...

if no on earlier request, any chance we could get a custom FTP command to make XM360 on XB write the report files?  My computer is a long way from my TV and I always am walking back and forth just to tell XM360 to write updated reports...then walking back to computer to FTP the reports and look at them  

Thanks for the donation!  Unfortunately, both of these requests would require some *real* effort.  The scenes that currently write the reports are the *only* scenes that actually have all of the required data... In other words, when you launch xm360, it doesn't even know about DLC (for example) until you enter the DLC scene.

I'll look into it to see how much of an effort it would really be.

-node

[node21]

Beta testers are currently testing this...if all goes well, it'll go public in a few days.

Version 2.0 -- Sep 26th, 2010

* Fixed 360 to 360 remote connections
* Added config command WRITE_REPORTS_ON_STARTUP, see xm360.cfg for more details
* Added custom FTP command "RPTS" which will write all 3 reports

-node21

[schoenof]

node21,

I am testing with 2.0...I found a small problem with RESC and RPTS FTP commands...

Did a full scan and created reports from the XBOX XM360 UI as normal...
Then went back to computer and uploaded a missing XBLA game...via FileZilla...
Issued custom FTP command RESC (connection timed out)...waited 5 minutes or so to let it finish rescanning...
Reconnected FTP and was able to verify that content.bin timestamp had changed....
Issued custom FTP command RPTS returned quickly and was able to verify that report timestamps had changed...

FTPed the reports back to computer and the XBLA game was still listed as missing...
repeated all the steps a 2nd time....still shown as missing from the report...

Went back to XBOX and check the XM360 GUI...Stills shows as missing in the collection management GUI...
Did rescan from XBOX XM360 GUI...now the XBLA game is FOUND and shown as HAVE and the report...

Something seems wrong with the RESC FTP command...seems like the rescan did not work correctly...
Am I missing something obvious here?  This is my first time using RESC....maybe I am misunderstanding the expected behaviour here (IMG:style_emoticons/default/smile.gif)


This post has been edited by schoenof: Sep 27 2010, 12:32 AM

[invivo]

Hi node21,

Just upgraded to the latest version and noticed some odd things and not sure if these have been addressed before:

1) When using xm360server to update the DLC, it seems to indicate that it is update some new titles and exits successfully.  However, when running the same command immediately afterwards, it indicates it is updating the same content again.  I checked the files, and the tiles that were updated were already in the csv.  It also does the same thing with a few titles for XBLA.

2) xm360server doesn't seem to download all the titles, and this is especially noticeable with the DLC database.  I ran the perl scripts, and the files sizes are significantly higher for the DLC.csv (~400K vs. ~900K), and to a lesser extent, the XBLA titles as well.

3) When generating reports, should it also show titles that are not matched?

Thanks, for your hard work and donation sent!

[node21]

QUOTE(schoenof @ Sep 26 2010, 07:28 PM)

I am testing with 2.0...I found a small problem with RESC and RPTS FTP commands...

Thanks for the detailed description.  Without even looking at the code, I know what's wrong.  I forgot about the RESC ftp command...it goes through a different codepath.  Trivial fix.  I'll try to get a 2.0a out ASAP.  Nice catch!

QUOTE(invivo @ Sep 26 2010, 10:14 PM)

1) When using xm360server to update the DLC, it seems to indicate that it is update some new titles and exits successfully.  However, when running the same command immediately afterwards, it indicates it is updating the same content again.  I checked the files, and the tiles that were updated were already in the csv.  It also does the same thing with a few titles for XBLA.

2) xm360server doesn't seem to download all the titles, and this is especially noticeable with the DLC database.  I ran the perl scripts, and the files sizes are significantly higher for the DLC.csv (~400K vs. ~900K), and to a lesser extent, the XBLA titles as well.

3) When generating reports, should it also show titles that are not matched?

Thanks, for your hard work and donation sent!

1) That's because it has no concept of "time".  If a title is listed as updated "today", every single time you tell it to update it will fetch the updates.
2) This has never been reported, and is quite worrisome.  The perl version doesn't know anything about dates...it just grabs the world.  Is the clock/date on your computer correct?  Are you downloading from the same region in both cases?  Are you downloading from the region with the same clock settings as your PC (that shouldn't matter since it's all GMT).
3) You'll have to clarify what you mean here.

(Not sure if you are talking about a new donation, or an old one...nothing new received, so check where you sent it?  Anyway, thanks for the thought! )

-node

[node21]

Okay, after some PMs from invivo, I understand what's going on.

The reason the perl downloader ends up with a MUCH bigger file that the xm360_server downloader is simply because the perl downloader is stupid.

There are TONS of duplicates in the resulting file.  You see, the marketplace lists, for example, Band Hero, and Band Hero II...They both have TONS of DLC...yet, all of the DLC for each is the same.  The perl scraper doesn't know this, and grabs them all (and xm360 filters the duplicates).  Xm360_server understands this, builds an internal map, and only spits out the unique DLC.  So, rest assured, you aren't missing anything by using the server.

As far as noting DLC that you have, but wasn't matched...It's there already.  In the "DLC that you have" section of the report, the second column of the CSV file is either "HAVE", or "HAVE_BUT_NOT_IN_DB".

Lastly, donation received, thanks!

[node21]

Currently being tested.  Hope this does the trick...I didn't have time to test it myself.

Version 2.0a -- Sep 27th, 2010

* Fixed RESC ftp command followed by RPTS command

-node

[invivo]

QUOTE(node21 @ Sep 27 2010, 02:53 PM)

There are TONS of duplicates in the resulting file.  You see, the marketplace lists, for example, Band Hero, and Band Hero II...They both have TONS of DLC...yet, all of the DLC for each is the same.  The perl scraper doesn't know this, and grabs them all (and xm360 filters the duplicates).  Xm360_server understands this, builds an internal map, and only spits out the unique DLC.  So, rest assured, you aren't missing anything by using the server.

Just an observation, but I noticed that the .exe omits some content that the perl script catches.  I noticed that several Lips DLC are listed in the perl .csv but not the .exe csv.  This may be the case with other content as well.  Has anybody else experienced this?  (BTW, Region = US)

[node21]

QUOTE(invivo @ Sep 28 2010, 04:57 PM)

Just an observation, but I noticed that the .exe omits some content that the perl script catches.  I noticed that several Lips DLC are listed in the perl .csv but not the .exe csv.  This may be the case with other content as well.  Has anybody else experienced this?  (BTW, Region = US)

Can you list some specific examples?

[schoenof]

node21,

RESC + RPTS working well in 2.0a...

Thanks for the extremely fast support