fix me beautifull
category: general [glöplog]
The readme of "Housemarque Audio System, release 1.1.2" says this:
To avoid problems, "hmqaudio.zip"
contains the original release of "MIDAS Digital Audio System", version 1.1.2,
and thus most of the documentation and source code inside the file still uses
that name. The name is obsolete, however, and all material referring to the
system must use the current name, "Housemarque Audio System".
-> IMHO we shoud keep both ;-)
To avoid problems, "hmqaudio.zip"
contains the original release of "MIDAS Digital Audio System", version 1.1.2,
and thus most of the documentation and source code inside the file still uses
that name. The name is obsolete, however, and all material referring to the
system must use the current name, "Housemarque Audio System".
-> IMHO we shoud keep both ;-)
There is a problem with this prod: ... please change demozoo link to https://demozoo.org/productions/303797/ the current link points to a dupe i created accidentally, sorry
Thanks for all the fixes :-) I guess there's no way of marking inode.at etc. as broken even though they don't properly return 404? (There's an amazing amount of such links that return obviously-not-the-correct-file but still 200 OK. :-/)
rufusul: yep, that was the bit in the NFO i was referring to. demozoo link is fixed (would've been less work for both of us if you had reported it via the automated edit request system though ;) )
sesse: cheers! only way i can think of to "mark" those prods is by entering a "fake link" that to trigger the tracking system. but imho that's a non-solution and therefore it's better to keep the deadlink in such cases. i try to keep record of such "false positives" in a spreadsheet, would be interesting to compare that to a list of those "obviously-not-the-correct-file but still 200 OK" files if you can export that somehow(?) :)
sesse: cheers! only way i can think of to "mark" those prods is by entering a "fake link" that to trigger the tracking system. but imho that's a non-solution and therefore it's better to keep the deadlink in such cases. i try to keep record of such "false positives" in a spreadsheet, would be interesting to compare that to a list of those "obviously-not-the-correct-file but still 200 OK" files if you can export that somehow(?) :)
Well, the problem is that it's hard to spot for a machine, even though it's easy for a human.
For instance, I have 186 prods that have one or more links to .zip files that, when I crawled them, were actually plaintext or HTML files. This could mean one of several things:
1. The download was non-direct, ie., you got to a landing page possibly with JavaScript, but you do get the file (e.g. scene.org or web.archive.org, except I've taken those out so that they don't count towards the 186).
2. The domain expired and was taken by a scalper, so you get some sort of landing page. These are broken, but not marked as such.
3. Like #2, but at some unknown point after I crawled, the scalper let go of the domain and now it's just a regular broken link (which Pouët will mark as such).
4. Like #2 or #3, but at some unknown point after I crawled, the domain was actually put back into working order, and now the file is there.
#1 and #4 are false positives from my side, #3 is uninteresting, #2 is what we're after—silent breakage, which is very bad. On a quick sample, I'd assume perhaps 50% of those 186 are of the #2 kind. I don't have re-crawl functionality, but it would be interesting to know at some point whether a file changed; you would assume that is bad somehow (except in the very rare cases where an archive is updated with a final version without changing names).
This is .zip only; of course, there will be other file types. But it gives some insight into how widespread or not we can assume this to be.
For instance, I have 186 prods that have one or more links to .zip files that, when I crawled them, were actually plaintext or HTML files. This could mean one of several things:
1. The download was non-direct, ie., you got to a landing page possibly with JavaScript, but you do get the file (e.g. scene.org or web.archive.org, except I've taken those out so that they don't count towards the 186).
2. The domain expired and was taken by a scalper, so you get some sort of landing page. These are broken, but not marked as such.
3. Like #2, but at some unknown point after I crawled, the scalper let go of the domain and now it's just a regular broken link (which Pouët will mark as such).
4. Like #2 or #3, but at some unknown point after I crawled, the domain was actually put back into working order, and now the file is there.
#1 and #4 are false positives from my side, #3 is uninteresting, #2 is what we're after—silent breakage, which is very bad. On a quick sample, I'd assume perhaps 50% of those 186 are of the #2 kind. I don't have re-crawl functionality, but it would be interesting to know at some point whether a file changed; you would assume that is bad somehow (except in the very rare cases where an archive is updated with a final version without changing names).
This is .zip only; of course, there will be other file types. But it gives some insight into how widespread or not we can assume this to be.
I narrowed the .zip list down to 152 by restricting myself to main download links and doing some checks; these are all manually verified to give a 200 OK but not the actual prod (usually landing pages). See https://pastebin.com/Zm1mSAmL . You'll probably want to massage it somehow :-)
BTW, three of them are from your own untergrund.net directory (the ones used to replace broken links with archived downloads, I suppose), which I guess shows that breakage is recursive :-)
those seem to be damaged archives, so yeah, breakage is recursive indeed :/ there were a bunch more of those but with help of warenetwork2k i managed to fix those. for those 3 prods i don't have a solution :(
anyways, thanks for the list, now i have something to chew on in the upcoming days :)
anyways, thanks for the list, now i have something to chew on in the upcoming days :)
Well, at least one of them was a Dropbox HTML page. So I guess just fetching missed it.
I'm looking into a re-crawl to find anything that's changed (which should tease out a large number of such quasi-404 pages, as they are rarely stable), but I fear there will be so many false positives that it will be useless as an indicator.
I'm looking into a re-crawl to find anything that's changed (which should tease out a large number of such quasi-404 pages, as they are rarely stable), but I fear there will be so many false positives that it will be useless as an indicator.
At least seemingly tons of files under www.pelulamu.net and http://zxm.speccy.cz/dwnld/ used to be zip files, but are now HTML :-) And there's more than 3000 URLs that have changed contents in one way or the other since my first crawl (many of these are probably GitHub and Soundcloud pages, though). Still discovering more as the crawl finishes.
URLs with type mismatches, ie., not only did the file change from one crawl to the next, its type did (but both crawls returned 200 OK). I've sampled many of these, and all of them look like genuine issues to me. There is some overlap with my previous list.
Thankfully these issues seem to cover less than 1% of Pouët's URLs. But I am a bit dismayed at how freely people change their stuff after putting it up on the site; it seems to be rampant. As an archivist, which version should one keep? Does one need to re-crawl regularly just to make sure nobody switched the contents behind your back?
Thankfully these issues seem to cover less than 1% of Pouët's URLs. But I am a bit dismayed at how freely people change their stuff after putting it up on the site; it seems to be rampant. As an archivist, which version should one keep? Does one need to re-crawl regularly just to make sure nobody switched the contents behind your back?
I added a dupe:
https://www.pouet.net/prod.php?which=90601
dupe of:
https://www.pouet.net/prod.php?which=75255
https://www.pouet.net/prod.php?which=90601
dupe of:
https://www.pouet.net/prod.php?which=75255
I added a dupe
https://www.pouet.net/prod.php?which=90582
Dupe of:
https://www.pouet.net/prod.php?which=73657
https://www.pouet.net/prod.php?which=90582
Dupe of:
https://www.pouet.net/prod.php?which=73657
done.
There is a problem with this prod: Please replace the cover image with this one: http://xk8.ru/files/temp/chaos_eq_pouet.png
done
There is a problem with this prod: ...
The download link doesn't bring to the product. Consider for removal.
The download link doesn't bring to the product. Consider for removal.
fixed the link. thanks for pointing it out!
There is a problem with this prod: ...
still getting notification that download link is broken, while it's working for a while now (fixed 5-6 days ago).
still getting notification that download link is broken, while it's working for a while now (fixed 5-6 days ago).
The script to check the download links apparently didn't run yet so the broken download link was not updated. I did this manually now.
done
done
There is a problem with this prod: Please could you add "Acorn" as a platform? Download link is https://bitshifters.github.io/content/bs-django01.zip.
