get diagnostics error in subfolders

[frozeman]

still get the diagnostic error in subfolders

Diagnostics

Could not open "D:\Creative\Server\htdocs_feindura_upload\test." (does not exist, or is not a file) error.0 Could not open "D:\Creative\Server\htdocs_feindura_upload\test." (does not exist, or is not a file) mime type text/directory cache hash 353354520e4a0c2ae722390a0e9dc46c cache file D:/Creative/Server/htdocs/_feindura/_upload/thumbnails/a8/3688_36885a663a16c2b5c62e10ab23f6de-info.nfo cache dir D:/Creative/Server/htdocs/_feindura/_upload/thumbnails/a8/

[GerHobbelt]

Weird. Don't know what is wrong there, as I cannot reproduce the issue here.

It's an error originating from getid3 and apparently I'm feeding that one the '.' directory name (as parameter for analyze()).

If you grep the code in FileManager.php, you'll notice that analyze() is only called in one place, inside getFileInfo(), where the path is checked whether it's a directory or not, and only in the latter case is passed to analyze(), so something really wicked must happen there. OR I'm completely mistaken in the analysis so far.

Either way, does the error go away if you add a check around the analyze() to only allow it to analyze paths which do NOT end in '.'? (Just a hack to test to see if we're warm or not.)

Oh, before I forget: nuke the entire thumbs storage tree ( rm -rf or rmdir /s ) is required when change these things; otherwise the code is all too happy to pick the old analyze result (error message and everything included) from cache.

[frozeman]

ok this does the job.

so the error is disappeared.

but the diagnostics table should look like the headers...

like information, without an upperline and the spaces of the information is alos not fitting the design of other elements above.

this should look the same, and also would i rename diagnostics to "more info" or so, this is more userfriendly. because its not made for programmers ;-) and nobeody els want to doiagnose something there.

so for the div.filemanager-diag-dump you should use the same elemnts:

<h2> <d> <dl> <dd> </dt>

etc

so they all have the ame spaces

[frozeman]

and alos shuld the page switcher text be

1/34

and not P: 1

this is not user friendly :-) if its not possible to determine the number of total pages, then just write

1

it looks much better

[frozeman]

ps is it necessary at all to show the diagnostics part? is this not to much useless information for the user? i think it should be an option in the filemanager.php but not standard

[frozeman]

ok i tried to rewrite it with dt but downs seem to work ..strange he still displays the table...

another thing is.

when i reload the page he diont open the filemangager again and jump to the position where i been? why is that? when i reload the page i always expect to be where i was.. or not?

[frozeman]

ok after deleting the cache it shows the dt list, maybe you want to give it a try? check my fork

[frozeman]

i also think there are to much encapsulated divs. from a webdeisgner standpoint this slows down the rendering of the page and make it difficult to change the layout when wished.

it should use as less as possible markup tags and style everything through css.

so my hints:

• make diagnostics an option which is off by default (dont stress your user with pages of unnecessary information)
• use the same elements for lisiting items everywhere, maybe you should all change it to <ul> ?
• users want to have a clean simple interface with alle information they need really visible, and not search in a bunch of text or long lists, for the right info. So i also wanted to change the appearance of the info block, when i was working on it, but i didnt (no time), because its quite messy there.
• focus your work more on how to present information and not which. right now its to technically in my opinion. all that have to be simplified.
  • change the pagination text to 1/34 or simple numbers e.g. "4"

thats just a few thoughts i get when i use the fm. hopefully it will help you improve the fm in an other direction (besides the underlaying invisible structure :-))

fabian

[GerHobbelt]

ok this does the job.

so the error is disappeared.

Good. The bad part is that this is still a bug I cannot reproduce, so I am unaware of what's going wrong exactly. Never mind that for now; major overhaul happening here after I had an epiphany how to trhow away several options and fix some troublesome issues alongside:

• propagateType=GET, URLpropagateData, ThumbnailAuth callback, 'thumbnail' request: will be gone
• caching issues in the backend where cache is so aggressive the thumbnail URLs don't get a chance to update
• 'select Image' has a bug where the metadata delivered onComplete generally points at PHP backend thumbnail query instead of thumb image(s) at a first run

but the diagnostics table should look like the headers...

like information, without an upperline and the spaces of the information is alos not fitting the design of other elements above.

Yeah, I know. It's rather technical stuff in there; structure is flattened as much as possible, but the intent is to have access to the getID3 on the client-side (and have a look at it). I use tables there because for this kind of (tech) data, that's way easier and neater looking than having a big hassle with nested dt/dd and all. It's tabular data after all, that's what a table is for. There's a div around it you can simply edit one line of CSS to get rid of it. Should become an option to the backend to include it or not, as well (cutting down on tx costs when client-side doesn't want that data).

this should look the same, and also would i rename diagnostics to "more

info" or so, this is more userfriendly. because its not made for programmers ;-) and nobeody els want to doiagnose something there.

I like the 'more info'. Will do it.

Also thanks for the page/total suggestion; much better than P:n

(Side note: the caching in the backend is pretty aggressive these days -- I like that ;-) -- so you should always nuke the thumbnails directory tree when doing something to the code there.)

In matters of 'looks', have a look-see at the ionize fork by partikule: I like what he did to the look/layout. Particularly the part where he's showing the image collection in a dir when you're looking at a directory itself. It still needs to be made to cope with pagination, but that's a technical matter.

Met vriendelijke groeten / Best regards,

Ger Hobbelt

---

web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: ger@hobbelt.com

mobile: +31-6-11 120 978

[GerHobbelt]

i also think there are to much encapsulated divs.

Don't know about that; the divs so far each have a purpose; they are used to switch blocks of info on/off. The only div that was added recently is the diagnostics block; maybe the three of them for regular view could be combined as right now they are switching on/off together. (When uploading, the upload info div is moved to the top by hiding the regular info divs; before, it was appended at the end of the current detail view)

Tech: the whole detail pane thing has been moved to the extractDetailInfo() method. Since I already realized from the start that the getID3 info is for a few people only, it's built in chunks. I currently have it turned on all the time -- and haven't spent time of providing an option to disable it -- because I use that data to 'diagnose' the processing of the media I have in my test dirtree. Quite a few errors/glitches showed thanks to that info. Also, some particular parts of that info are to be used by custom code in client and backend, so option to turn it off comes later, but will happen.

from a webdeisgner standpoint this slows down the rendering of the page and

make it difficult to change the layout when wished.

slow down, yes. Current divs should allow a designer to more easily adjust the rendering of particular chunks, me thinks. Ah well, we'll iron that one out when the time comes.

it should use as less as possible markup tags and style everything through

css.

so my hints:

• make diagnostics an option which is off by default (dont stress your user with pages of unnecessary information)

will happen

• use the same elements for lisiting items everywhere, maybe you should all

  change it to <ul> ?

basic dt/dd is fine everywhere; just the ID3 data is more suitable for nested tables; unless you know a way to make it render easily (and no annoying wrapping and scrollbars where they shouldn't be) with dt/dd. I'm not a CSS guru and given my own start with it (using dt/dd) and your trouble 'reverting' to that, I'd say tables are the better choice for now. It's work in progress there and seeing the data is most important for me right now. 'everywhere' only applies if it's all the same and the id3 output is definitely not the same as the (flat) rest: it's got hierarchy, where the other chunks don't have/need hierarchy.

One /might/ go and use ul/li or dt/dd nesting on the diag tree instead so it can be rendered as a (collapsable?) tree, e.g. http://mootree.mindplay.dk/example_5.html ( https://sites.google.com/a/mindplay.dk/mootree/Home ) or http://www.clientcide.com/wiki/cnet-libraries/07-ui/02-objectbrowser

Anyhow, the idea is to move it entirely to JSON anyway when I'm done cleaning the ID3 output, then the frontend can decide on it's own how to render the stuff. ul/li or dt/dd or table or whatever.

Met vriendelijke groeten / Best regards,

Ger Hobbelt

---

web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: ger@hobbelt.com

mobile: +31-6-11 120 978