XMB Package Downloader (XMBPD)

PS3 XMB Package Downloader - An XMB MOD that intergrates a Homebrew Store on the XMB v0.70

Thanks for your reply. I suggest you check category_game.xml and category_game_tool2.xml in Rebug. It has the following 2 queries added (the 1st is for XMBM+ and the 2nd is for webMAN).
Code:
<Query
class="type:x-xmb/folder-pixmap"
key="seg_package_files"
src="xmb://localhost/%flash/xmb/category_game.xml#seg_package_files"
/>
<Query
class="type:x-xmb/folder-pixmap"
key="xmb_app3"
attr="xmb_app3"
src="xmb://localhost/dev_hdd0/xmlhost/game_plugin/fb.xml#seg_fb"
/>

Indeed I suggest you and all the other devs that use Rebug as the model to follow and improve. It is the result from many talented devs (not only Evilsperm, Cyberskunk, Joonie, Habib, Abkarino).

BTW I saw that you included a custom version of webMAN MOD. It has a combo to disable Cobra, but you forgot to change the path to point to the your custom location of stage2. If you use the standard location in /dev_flash/sys, then you don't have to make changes and the updates in my github would be alsocompatible with your CFW.


Thank you I will look and make the appropriate changes,
Yes I used 1.43 webman, Unfortunately I am not very good as I move from project to project and try to do too many tasks at once so I miss things,
Would it be ok if I used your version of webman with some minor changes such as pictures and language ?
I really like coloured webman folders and the webman face for the settings.

Also is your github name Aldostools ?
 
BTW: You should post about unique patches like this when you discover or apply them. At least put them on your "Features" list, I would have never known your 4.80 CEX actually supported XMBPD all along, Ive been telling people it was Rebug only since the start.

I will add it to the features,
also now it can be for all cfw cuz you can add the download plugin file :)
Also XMBPD should work on all dex cfw, cuz the download plugin must always be patched on dex for game updates.
 
Thank you I will look and make the appropriate changes,
Yes I used 1.43 webman, Unfortunately I am not very good as I move from project to project and try to do too many tasks at once so I miss things,
Would it be ok if I used your version of webman with some minor changes such as pictures and language ?
I really like coloured webman folders and the webman face for the settings.

Also is your github name Aldostools ?

My github: https://github.com/aldostools

You can make all the changes that you want... that's the purpose of open source projects ;) It would be nice if you could create a fork, label it so the users know that it's a fork (not need to use "unofficial"), and make public your changes to the source code in github, so if there are some features that I am interested, I could implement them in the trunk for the benefit of the rest of the users.
 
My github: https://github.com/aldostools

You can make all the changes that you want... that's the purpose of open source projects ;) It would be nice if you could create a fork, label it so the users know that it's a fork (not need to use "unofficial"), and make public your changes to the source code in github, so if there are some features that I am interested, I could implement them in the trunk for the benefit of the rest of the users.

Thank you,
Yes I will make an account with github and add the source post changes,
I would say that I will add you to my credits for cfw but I already do lol,
Also not sure if I got round to saying thank you for ps3tools, but thank you :P
 
Ok guys.. Nice progress made on this issue since I signed off last...
I was wondering though about the level at which the patch should be applied.
Of course most CFW makers can do that but what about standard CEX like Ferrox? We all argued that it should remain as close to ofw as possible...

Mamba/Cobra could easily take care of it. Atm webMAN-MOD is the only brew that uses download_plugin.sprx AFAIK (except mysis's original xmb cfw settings which had a download link calling the download plugin through his xai_plugin). And wMM needs Cobra or Mamba to run so...
However only the latest mamba/cobra would be compatible with wMM (and XMBPD by proxy).

Another option would be to patch dynamically the sprx at webMAN-MOD level, that would avoid all sorts of compatibility issues... Wouldn't it?

@aldostools @DeViL303 @Bobby_Downgrades ?
 
Last edited:
Should someone update the psdevwiki error code reported by DeViL303 & add downloading pkg as a potential source for the error, not just installing pkg..?
@sandungas maybe?
 
Ok guys.. Nice progress made on this issue since I signed off last...
I was wondering though about the level at which the patch should be applied.
Of course most CFW makers can do that but what about standard CEX like Ferrox? We all argued that it should remain as close to ofw as possible...

Mamba/Cobra could easily take care of it. Atm webMAN-MOD is the only brew that uses download_plugin.sprx AFAIK (except mysis's original xmb cfw settings which had a download link calling the download plugin through his xai_plugin). And wMM needs Cobra or Mamba to run so...
However only the latest mamba/cobra would be compatible with wMM (and XMBPD by proxy).

Another option would be to patch dynamically the sprx at webMAN-MOD level, that would avoid all sorts of compatibility issues... Wouldn't it?

@aldostools @DeViL303 @Bobby_Downgrades ?

Ill leave it up to you the experts, but my opinion, with Ferrox patching cobra files, using package manager, and red icons etc, there shouldn't be too much issue with using another small patch on another sprx, after all Rebug users have been using this patch essentially on np environment for years so it cant be a file that will get you a quick ban..for example. So I feel it would be better to patch it on the Fw level.

The other option (not the best but its there) is for no one to change anything and I will just include the correct patched sprx in the XMBPD flash files, as flash files need to be modded anyway it is no bother to add an extra one. If someone else utilises the WMM pkg handling commands in their app/mod then they can do the same.
 
I do not either TBH.
Am only weighing the different options & consequences...
What about Cobra/Mamba vs CFW ?

In my experience cobra cfw has too many advantages to not use, the main thing I find useful with cobra/mamba/webman cfw is the fact you have many functions such as fan control and setting cid at boot in one place,
while there are pkgs for many functions it's nice to have everything in one place and saves time in some cases,
I remember having to open multiple packages before being able to go online (the dark ages lol),
I would have given my right arm for cobra and webman on true blue cfw :p

Also about your previous comment about the patches and keeping cfw as close to ofw as possible,
to a certain degree I totally agree, The way I look at it is like this,
as many helpful patches or changes should be applied to ofw as possible as long as they are dead patches,
what I mean by that is they only come into use when certain functions are used/called and don't interfere with the general usage of the ps3,
as an example the patches in the download_plugin only affect the running when a download is done and the rest of the time they are dormant,
I agree with @aldostools and think if we can do as much work as possible in the base (the cfw) we leave less work to be done later (developing homebrew).

I have been looking at maybe applying the patches that cobra makes to the files, as I was wondering if this would reduce memory usage,
but I'm not sure it's possible as it was just a passing thought and something I haven't really looked into yet,
but I wonder what the result of that would be, I think maybe @haxxxen did it with his rebug port of 7.1 but I may be wrong,
@aldostools could you speculate on the last few lines please.
 
In my experience cobra cfw has too many advantages to not use, the main thing I find useful with cobra/mamba/webman cfw is the fact you have many functions such as fan control and setting cid at boot in one place,
while there are pkgs for many functions it's nice to have everything in one place and saves time in some cases,
I remember having to open multiple packages before being able to go online (the dark ages lol),
I would have given my right arm for cobra and webman on true blue cfw :p

Also about your previous comment about the patches and keeping cfw as close to ofw as possible,
to a certain degree I totally agree, The way I look at it is like this,
as many helpful patches or changes should be applied to ofw as possible as long as they are dead patches,
what I mean by that is they only come into use when certain functions are used/called and don't interfere with the general usage of the ps3,
as an example the patches in the download_plugin only affect the running when a download is done and the rest of the time they are dormant,
I agree with @aldostools and think if we can do as much work as possible in the base (the cfw) we leave less work to be done later (developing homebrew).

I have been looking at maybe applying the patches that cobra makes to the files, as I was wondering if this would reduce memory usage,
but I'm not sure it's possible as it was just a passing thought and something I haven't really looked into yet,
but I wonder what the result of that would be, I think maybe @haxxxen did it with his rebug port of 7.1 but I may be wrong,
@aldostools could you speculate on the last few lines please.

IMO the CFW should *look* like OFW with very little mods (as the default settings).
That means no fancy fonts, no fancy waves, no annoying sounds, no branded coldboots, no changed themes or icons.

Any extra mod should be done through a modding app (like Rebug Toolbox does).

Regarding to the patches, my opinion is that Cobra/Mamba should have all the patches that the developer want to include.
Any new patch should be configurable (optional) and not enabled by default.

When Cobra/Mamba is disabled the CFW should boot as clean as possible. It is not a good idea to not include peek/poke like Rogero 4.46 Cobra. Only basic syscalls (like peek/poke) should be included to allow to install payloads like prx loader, mamba, etc.

Regarding applying the patches directly to files, I don't see much advantages when Cobra/Mamba already do it.
To save some memory first you would have to remove the code of these patches also from Cobra source code, or even better unload Cobra from memory when it's not needed anymore (which is difficult to tell, specially if the user is using ISO). Anyway the payload is only 81KB, so it doesn't have a big impact is memory usage.

One advantage of having the patches in Cobra/Mamba is that they are applied only in memory. If Cobra is disabled, the files remain unaltered and loaded clean. Thus there is less chance of conflicts or no need to "unpatch" memory in homebrews.
 
IMO the CFW should *look* like OFW with very little mods (as the default settings).
That means no fancy fonts, no fancy waves, no annoying sounds, no branded coldboots, no changed themes or icons.

Any extra mod should be done through a modding app (like Rebug Toolbox does).

Regarding to the patches, my opinion is that Cobra/Mamba should have all the patches that the developer want to include.
Any new patch should be configurable (optional) and not enabled by default.

When Cobra/Mamba is disabled the CFW should boot as clean as possible. It is not a good idea to not include peek/poke like Rogero 4.46 Cobra. Only basic syscalls (like peek/poke) should be included to allow to install payloads like prx loader, mamba, etc.

Regarding applying the patches directly to files, I don't see much advantages when Cobra/Mamba already do it.
To save some memory first you would have to remove the code of these patches also from Cobra source code, or even better unload Cobra from memory when it's not needed anymore (which is difficult to tell, specially if the user is using ISO). Anyway the payload is only 81KB, so it doesn't have a big impact is memory usage.

One advantage of having the patches in Cobra is that they are applied only in memory. If Cobra is disabled, the files remain unaltered and loaded clean. Thus there is less chance of conflicts or no need to "unpatch" memory in homebrews.


Some good points Aldo thank you,
I disagree with coldboot and icons, I like to boot up ps3 with a different look, but thats personal opinion, I wanted to have stock xmb with an option inside cfw to change the icons to any colour you want, say 5 choices but dev_flash space is tight,
even after unpacking and resigning the whole module and syscon fw I still had not enough space to fit what I wanted,
but then with help from devil and maybe putting xmbpd into cfw the option would be there from installation for people who want to change the look,
Also thanks for the info about the memory, would be a disadvantage to pre patch modules so I think I will avoid that.
 
Some good points Aldo thank you,
I disagree with coldboot and icons, I like to boot up ps3 with a different look, but thats personal opinion, I wanted to have stock xmb with an option inside cfw to change the icons to any colour you want, say 5 choices but dev_flash space is tight,
even after unpacking and resigning the whole module and syscon fw I still had not enough space to fit what I wanted,
but then with help from devil and maybe putting xmbpd into cfw the option would be there from installation for people who want to change the look,
Also thanks for the info about the memory, would be a disadvantage to pre patch modules so I think I will avoid that.

There is always the option to have add-ons packages for your CFW that can be installed separately.

My opinion about coldboot, icons, theme, etc. is that the look should be a decision of the end user, not something forced by the dev.
Anyway it's only my personal opinion and I don't expect that everyone will agree with me. :)
 
There is always the option to have add-ons packages for your CFW that can be installed separately.

My opinion about coldboot, icons, theme, etc. is that the look should be a decision of the end user, not something forced by the dev.
Anyway it's only my personal opinion and I don't expect that everyone will agree with me. :)

I was thinking about a small pkg inside dev flash that downloads full version of my xmb editor,
I must spend some time making various colour schemes first lol.
 
How come we cant make the PUP like 250MB with 50MB installed to HDD?


The pup install is quite tedious,
When first looking at adding pkgs into the flash I soon realised that with the limited space I would not be able to add say multiman,
so I looked into adding a new pkg into a pup that will install to hdd,
from what little research I have done (which is not much) I think the pup is unpacked and tmp checked in a sand box inside the flash (maybe)
I think it only has the capability to install to the flash via update process,
one thing that leads me to believe this is singstar, the way it downloads it's tmp files from psn.
Good idea and if anyone knows how we could do it (or at least point us in the right direction) I would be up for doing that.
 
Do you mean to hijack the xil2 mechanism? By way of xml, use xil to download files automatically & make new entries appear on xmb...?
 
I think he meant to have extra non essential files included in the PUP that install to HDD when the PUP installs, is this possible? the PUP can install files to HDD in some way as it does if you replace the hdd, but I never see people include custom files.
 
Back
Top