Pandora PNDManager


I hardly think the unfinished sync is the issue here. With new versions, sync only takes a few seconds to complete.

Danielm, have you noticed if this problem appeared with the latest version, or even before? It might help if you confirm which version is the origin of the bug by running a couple of archived versions from the repo. Also, you should check if the bug is reproducible by removing appdata/pndmanager, appdata/libpndman and /mnt/utmp/pndmanager (you might want to back up your settings), then running it again.
Puh, I am almost sure it started with the version that introduced queuing. I will try my best, but it happens only sporadically, and that makes it difficult to test ...
 
There may be some cases I haven't considered where the UI updates and backend changes are not handled in correct order which would cause this behavior. Given that in those cases there's both threading and async message passing going on, they're quite hard to debug without specific repeatable cases where they go wrong :p . The design for Panorama's PNDManagement-plugin (basically the thing between PNDManager UI and libpndman) has changed so many times some spaghettification has started to emerge :D
 
Another question: how can I make my app show up in a particular category? I have


<categories>
<category name="Utility">
<subcategory name="FileTools"/>
</category>
</categories>

but I don't see my app under "Utilities"
 
It should. The metacategories in PNDManager are defined as regexp filters, as seen here. If it doesn't, libpndman does not, for one reason or another, report its category as "Utility". Have you validated your PXML to make sure it's not malformed? Any PNDs I've tested seem to work fine, so no idea without further investigation.
 
A close look at my PXML file showed that I had the "icon" tag defined twice. Might that be it? I will check this out with the next release I guess.
 
feature Req.: the ability to move .pnd files [and, if possible, the associated folders] between usb/sd media.


note: I'm assuming that the folders part won't be easy, unless there's some way to parse that info out of the .pnd/.pxml file, so I'm going to also assume that it's too difficult to even make an effort on, but I wouldn't mind being proven wrong! :)


meanwhile, I just want to say that I LOVE this app!
 
Under Slack, the case where no SD or USB drive is inserted (except the rootfs card) leads to a "null" not handled when installing an app.

Is it possible to have the /pandora/menu or whatever suited on the rootfs to receive .pnd ?

Or maybe there is a way to handle this case tweaking a .conf ?

(also posted on other thread)
 
I hardly think the unfinished sync is the issue here. With new versions, sync only takes a few seconds to complete.

Danielm, have you noticed if this problem appeared with the latest version, or even before? It might help if you confirm which version is the origin of the bug by running a couple of archived versions from the repo. Also, you should check if the bug is reproducible by removing appdata/pndmanager, appdata/libpndman and /mnt/utmp/pndmanager (you might want to back up your settings), then running it again.
I downloaded the debug version of PND manager, but it crashed while updating PNDs. The .out contains a lot of lines saying "Unable to find libthread_db matching inferior's thread library, thread debugging will not be available." (my Pandora is running SZ1.60). At the end, I see a segmentation fault, but I don't think it  is related to my stuck downloads, but rather another issue that was fixed in v1.3.6.6.

One thing I noticed is that the download speed sometimes shows big negative numbers (e.g. jumping from +120.81 KiB/s to -200000? KiB/s). The download progress also jumps back and forth (e.g. 50.15 MiB -> 49.68 MiB -> 50.26 MiB ...). Then, when the download is finished, it stops at 100 %, nothing else happens and the app in question is stuck in the queue. The .out says that the MD5 check for the stuck PND failed (error in handle.c, line 444 >> _pndman_package_handle_install).

The negative download speed and jumping progress is only visible for the blink of an eye, but very often. I have no idea what could cause this behaviour. Maybe my internet connection is too crappy (slow, lost packages, ...). Could it be that PNDManager calculates the progress wrongly due to these  glitches and stops the download before it is complete? An incomplete file would explain the failed MD5 check. Does PNDManager check the file size at the end of a download? Or could it be even worse and the jumping causes the PND to become completely garbled?

Will the PNDs be downloaded to their final destination directly, or are they stored in a temporary folder until complete? I'd like to looka at a failed PND next time ...
 
The "Unable to find libthread_db matching inferior's thread library, thread debugging will not be available." is nothing to worry about. Could you PM me the .out?

I've seen the jumping behavior sometimes, and I think it's a concurrency issue. It shouldn't change the end result, however.

The failing MD5 check may be the result of a bad connection. Cloudef should answer this part since it's in his domain.
 
The failing md5 check might be that the repository db isn't up-to-date as well (contains wrong md5 for the file you are downloading).

Try syncing or removing repo.db from libpndman appdata and syncing again, if that dint work.
 
Last edited by a moderator:
The failing md5 check might be that the repository db isn't up-to-date as well (contains wrong md5 for the file you are downloading).

Try syncing or removing repo.db from libpndman appdata and syncing again, if that dint work.
I've seen this quite a lot...  usually (but not always) happens when downloading a bunch of things at once.

I always sync the db first thing when I start PND Manager. (i.e. moments before starting the download)

If I restart PNDManager (deleting the failed download file on shutdown) and redownload the file that gave me trouble, it usually works ok the second time around.

- Neelix
 
The failing md5 check might be that the repository db isn't up-to-date as well (contains wrong md5 for the file you are downloading).

Try syncing or removing repo.db from libpndman appdata and syncing again, if that dint work.
Well, I usually re-start PNDManager right away and continue updating PNDs. This usually works, and I would be surprised if the MD5 sums would change within a few minutes. Next time, I will not sync before re-downloading updates.

(I will post the .out files later)
 
The out files probably don't help much in this case. It might be just bad network. And even when there is HTTP resume supported, even that seems to fail from time to time (pnd gets corrupted) for unknown reason. The progress bar and stuck install / update problems might be concurrency issue however like B-ZaR mentioned.
 
The issue with bad downloads started when a PHP upgrade broke the repo, and suddenly the server started providing bad data mid download.   Sometimes that bad data was in plain text, so was able to be identified, and those cases were stopped.  But I'm wondering if the root cause of that issue is still unsolved and causing occasional data corruption for the same reason.

Currently the only way to recover from this situation is to delete the file manually or restart PND Manager.   Perhaps a good solution would be an option to restart a download from the beginning if the size of the downloaded file is equal to or greater than the reported size of the file being downloaded and the md5 doesn't match?

- Neelix
 
The out files probably don't help much in this case. It might be just bad network. And even when there is HTTP resume supported, even that seems to fail from time to time (pnd gets corrupted) for unknown reason. The progress bar and stuck install / update problems might be concurrency issue however like B-ZaR mentioned.
The .out files would be for the crashing. He's using the debug version with extra output that might be helpful.
 
Last edited by a moderator:
 The .out files would be for the crashing. He's using the debug version with extra output that might be helpful.
I see, in that case it might be more helpful then.
 
Suggesting a few feature improvement concerning item focus in lists:

After removing a PND and returning to the list, the next sibling of the deleted item shall be selected (focused)

Currently: If you remove a PND and return to the list (via the X-button) PNDmanager selects the first PND in the list.

Example: I currently do a PND housecleaning on my Pandora — reducing PNDs I rarely use — and this behavior is extremely annoying.

Going through that list would be far easier and quicker if PNDmanager would remember the following item after the current item, and selecting it if the current gets removed instead of loosing your context by jumping to the first item.

I am suggesting to select the following item rather than the previous item, because mostly you edit a list from top to bottom (regardless of your sort option) thus you already went over the previous item.

Side note:

The default file manager Thunar sucks in a similar regard — not even in the special case of deleting an item, but just with mere hierarchy navigation it sucks!

Good interaction design in a file browser: If you return to a parent item, it should have the folder selected from which you just came.

Thunar just has nothing selected and adjusts the window scrolling to the very top. If you were in a very long list, it could happen that you do not even see the folder from which you just came, if it happens to be below the fold. This is a navigational concept where you have nothing to hold on! You have to start from the beginning each time! Sucks big time. Especially in long/deep folder/listing structures.

Removing characters from "filter as you type" shall keep currently selected item selected

If you remove characters, you do this for these main reasons

1) You want to delete the whole string in order to

a) see the entire list again

B) retype an entirely new query

2) You mistyped the recent 1-2, at most 3, characters and want to correct your mistake.

3) Rare case: You get too little results, and want to find a smaller common denominator for getting more results.

As of now PNDmanager differs conceptually (I guess not by voluntary interaction design, but just by the way the code handles this use case)

Removing a character is treated as "creating a new query", thus changing focus. Which makes little to no sense at all.

Rare exception: Nr 3. But still in that case: The focus should still be kept on your currently selected item, only the amount of result should change.

I propose the following: Removing characters does only alter the results but not the selection.

The current selection WILL match the new query which is 1 character shorter than the previous one.

Except when the query is entirely removed (technically when it reaches NULL characters length).

Still then it is good to keep the most recent item selected and within the viewport.

(You probably used the instant type not as a filter but as a "quickly jump to the item matching my input but keep the rest visible", and although PNDmanager does not use this approach but rather an "instant filtering" approach, you nevertheless get this final result after having cleared the input again, thus you get the functionality of both concepts).
 
Last edited by a moderator:
Feature suggestion: Arrow-Right acts as Page-Down, Arrow-Left acts as Page-Up

Like in PickleLauncher. Works like a charm for scrolling through long lists.

As A/B/X/Y within list view are already in use in PNDManager.
 
Back
Top