Messages

16

Beta / Re: Testing build #131

« on: September 06, 2007, 08:35:09 PM »

+ kbps in bandwidth graph

Are you planning to implement the graph editing option about which there was a thread a while ago? ..to let the user deside what info the graph would show (and using which colors). Personally I don't like this "--- 7040 kbps" text there at all.  I'm able to convert KB/s to kbps in my head naturally

17

Bug reports / Re: Upload broken with small files

« on: September 03, 2007, 02:38:05 PM »

No change here with #129, randomly stuck 99% or "receiving" on some file. On first test I got the List index out of bounds (1) when HFS was disconnecting a timed out upload ...but not after that anymore.

Here's the log of the third test:

17:28:56 127.0.0.1:1280 Got 555 bytes
17:28:56 127.0.0.1:1280 Requested GET /upload folder/
17:28:56 127.0.0.1:1280 Served 1,02 KB
17:29:03 127.0.0.1:1280 Disconnected - 1047 bytes sent
17:29:03 127.0.0.1:1281 Got 712 bytes
17:29:03 127.0.0.1:1281 Uploading 9B_test_file.txt
17:29:03 127.0.0.1:1281 Fully uploaded -  9 B @ 0 KB/s
17:29:03 127.0.0.1:1281 Uploading 76B_test_file.txt
17:29:04 127.0.0.1:1281 Fully uploaded -  76 B @ 4 KB/s
17:29:04 127.0.0.1:1281 Uploading 261B_test_file.txt
 ## All three files visible in the upload folder
 ## 261B_test_file.txt stuck "receiving"
*** I think here should be "Disconnected by server: inactivity" but it gave it only in the first test (along with List index out of bounds (1)).
 ## Browser returns "page not found"
 ## 127.0.0.1 displaying "disconnected" in connections dialog, cannot be kicked!
 ## Unable to delete 261B_test_file.txt from the upload folder, other two delete OK

..had to restart HFS to be able to delete the file and get 127.0.0.1 away from the connections dialog.

18

Bug reports / Re: Upload broken with small files

« on: September 02, 2007, 06:09:50 PM »

Tested locally with three small files using build #128. Here's the log w/ comments:

20:53:07 127.0.0.1:3180 Requested GET /upload folder/~upload
20:53:07 127.0.0.1:3180 Served 1,30 KB
20:53:07 127.0.0.1:3180 Got 601 bytes
20:53:16 127.0.0.1:3181 Disconnected - 92642 bytes sent
20:53:16 127.0.0.1:3186 Got 712 bytes
20:53:16 127.0.0.1:3186 Uploading 9B_test_file.txt
 ### only 9B_test_file.txt visible in the upload folder
 ### 76B_test_file.txt stuck at 99% in the connections table
20:54:08 127.0.0.1:3180 Disconnected by server: inactivity - 46061 bytes sent
20:54:17 127.0.0.1:3186 Disconnected by server: inactivity
 ### Browser returns "page not found"
 ### 9B_test_file.txt disappears from the upload folder, folder empty

So not much change from my previous logs reports.

Second test:

21:00:19 127.0.0.1:3207 Got 580 bytes
21:00:19 127.0.0.1:3207 Requested GET /upload folder/
21:00:19 127.0.0.1:3207 Served 1,02 KB
21:00:19 127.0.0.1:3208 Got 594 bytes
21:00:19 127.0.0.1:3209 Got 594 bytes
21:00:19 127.0.0.1:3210 Got 594 bytes
21:00:27 127.0.0.1:3207 Disconnected - 2668 bytes sent
21:00:27 127.0.0.1:3211 Got 712 bytes
21:00:27 127.0.0.1:3211 Uploading 9B_test_file.txt
21:00:27 127.0.0.1:3211 Fully uploaded -  9 B @ 0 KB/s
21:00:27 127.0.0.1:3211 Uploading 76B_test_file.txt
 ### 9B_test_file.txt & 76B_test_file.txt visible in the upload folder
 ### The last file, 261B_test_file.txt, stuck at 99%
21:01:20 127.0.0.1:3208 Disconnected by server: inactivity - 583 bytes sent
21:01:20 127.0.0.1:3209 Disconnected by server: inactivity - 118 bytes sent
21:01:20 127.0.0.1:3210 Disconnected by server: inactivity - 578 bytes sent
21:01:28 127.0.0.1:3211 Disconnected by server: inactivity
 ### Browser returns "page not found"
 ### 76B_test_file.txt disappears from the upload folder, only 9B_test_file.txt left there

Third test same as the second.

Fourth one:

21:04:32 127.0.0.1:3215 Got 555 bytes
21:04:32 127.0.0.1:3215 Requested GET /upload folder/
21:04:32 127.0.0.1:3215 Served 1,02 KB
21:04:39 127.0.0.1:3215 Disconnected - 1046 bytes sent
21:04:39 127.0.0.1:3216 Got 712 bytes
21:04:39 127.0.0.1:3216 Uploading 9B_test_file.txt
21:04:39 127.0.0.1:3216 Fully uploaded -  9 B @ 0 KB/s
21:04:39 127.0.0.1:3216 Uploading 76B_test_file.txt
21:04:39 127.0.0.1:3216 Fully uploaded -  76 B @ 5 KB/s
21:04:39 127.0.0.1:3216 Uploading 261B_test_file.txt
 ### All three files visible in the upload folder
 ### 261B_test_file.txt stuck "receiving" (no %-bar visible)
21:05:39 127.0.0.1:3216 Disconnected by server: inactivity
 ### Browser returns "page not found"
 ### 261B_test_file.txt disappears from the upload folder, 9B_test_file.txt and 76B_test_file.txt succesfully uploaded

Fifth test same as the first one.

Sixth test same as the second one.

Seventh & eighth test same as the first one... so it's totally random.

...exactly the same results as before.

19

Beta / Re: Testing build #128

« on: September 01, 2007, 08:21:26 PM »

* "Open in Browser" works OK here

* Help & Web links OK too

* Uploading small files still not working

20

Bug reports / Re: Upload broken with small files

« on: September 01, 2007, 08:08:18 PM »

No change here with #128, sorry

I think what we need is a totally different approach to this problem. Could you make a separate beta version of HFS with the uploading part totally rewritten and using totally different "methods" for delivering the data? Don't mind if it would break everything else in HFS... We need something radical to beat this irritating little bug.

21

HFS ~ HTTP File Server / Re: Feature Req: Utilizing thumbs.db for image gallery

« on: August 31, 2007, 09:12:02 PM »

-- the static link (<IMG SRC="/thumbs/drive/original/album/path/%item-name%">) is not water-proof: if 2 images have the same name but are both in a different folder, they will both have the same thumbnail (cause of the thumbnail having the same name), But you will be able to set a relative path of your own instead of our ./previews_and_thumbnails/

It is waterproof since those "drive", "original", "album" and "path" are set to the Diff template by the generator. Maybe I should have clarified it a bit more..

F.ex: Your gallery is at D:\Images\MyGal1. The generator creates folders "D", "Images" and "MyGal1" to the HFS program folder one inside another and the thumbs inside the last one. The thumnail images at the gallery page are now pointed to <IMG SRC="/thumbs/D/Images/MyGal1/%item-name%">.
I don't see how this wouldn't be waterproof...

22

HFS ~ HTTP File Server / Re: Feature Req: Utilizing thumbs.db for image gallery

« on: August 31, 2007, 08:39:56 PM »

It doesnt need to edit the VFS at all :S, there's a way to set a diff template externally: 'hfs.diff.tpl'. It just has to be placed in the folder where you want that tpl to be active in and that folder, aswell as the sub-folders, will have that template.

  That's again something new for me. But as I already said in my previous post, I don't like any program "messing up" my photo archives (actually, I've even locked all the albums with ntfs rights so that changing their contents is not possible ). So I think adding only Diff template settings into VFS for the gallery folders would be pretty neat solution. Diff template can be used to override just some sections of the main template (like the [files] & [style] I already mentioned), doesn't it(?)

1) Find my HFS & it's setting from my machine (reg or ini)
-- Why, to find the .vfs?
  --yep
...
3) Close HFS (to save any possible changes to the current VFS)
-- Why not just save options?
  --is it possible to just command HFS to save its current VFS?
...
This way it might be easy enough even for novice.
-- doubt it, they would only understand it if they have used HFS for a while, i didn't know about Diff Template till a few months ago. We'd have to clearly state in the generator "Apply Gallery Template to this folder" in a right click menu i think.
  -- of course most of those procedures would be totally automatic and invisible to the user. Users should only start the generator, select which folders to apply the gallery for, maybe select recursive or not and click OK. Everything else would be set automatically but would be still customizable by clicking some "Advanced" button.
...
I think there also should be an option to save the thumb either to the folder where the original images are OR to HFS's program folder.
--I don't think the HFS's program folder part is viable. Link is better to be the same for all think.
  --Why wouldn't it be viable? I think it's very easy to set the gallery template to fetch the thumbs like <IMG SRC="./thumbs/%item-name%"> OR <IMG SRC="/thumbs/drive/original/album/path/%item-name%">. With "Save to HFS folder" option selected, the generator would add that (hidden, not browsable) real folder named "thumbs" to the VFS root.

23

HFS ~ HTTP File Server / Re: Feature Req: Utilizing thumbs.db for image gallery

« on: August 31, 2007, 10:30:10 AM »

I would be satisfied if your generator could:

1) Find my HFS & it's setting from my machine (reg or ini)
   - If it can't find it from the defaut location then of course ask
2) Find out (from the settings file) what VFS file I use currently
3) Close HFS (to save any possible changes to the current VFS)
4) Load that VFS into generator
5) Allow me to simply select which folders I'd like to have the gallery for (and optionally their subfolders)
6) Generate images & edit the VFS respectively (apply Diff Template for the gallery folders)
7) Save VFS and load it to HFS again 

...This way it might be easy enough even for novice.

I'm not sure about the (6), if it's the best way to do things...just the first idea that came to me. It means that the generator would also have those .tpl files matching HFS's templates. These *.gallery.tpl's would have only the [files] section (and maybe [styles]) edited to display thumb gallery. This way ToG, Terayon and the default template could all have their own editable gallery.tpl files which would then be set as the Diff Template for the gallery folders. Hope you understand what I'm trying to say

I think there also should be an option to save the thumb either to the folder where the original images are OR to HFS's program folder. Personally I hate if something (like some image viewers) create index files or something like that to my image folder thus destroying folder dates & times.

24

HFS ~ HTTP File Server / Re: Feature Req: Utilizing thumbs.db for image gallery

« on: August 30, 2007, 06:57:27 PM »

Attached is what the inside of thumbs.db actually looks like... for laughs ... what language is that...

Binary language 

As for the ToG & Terayon thumb generator, it's very good but not near as simple and straightforward as I'd like this whole precedure to be. It's a bit easier than using XnView though, but since I'm not using ToG or Terayon, there's not much use for it. You see, I have a few not so tech-savvy friends who'd like to share their images like I have done with my HFS & XnView. They are hardly able to drag & drop files and folders into their HFS to share them ..so it shouldn't be any harder than that.

I only now found out that it's only WinXP and Vista that use thumbs.db and even they in different ways, so maybe that's not a good solution afterall (...and linux (at least kde) stores thumbs in a hidden folder inside user's home dir.)

So I think HFS should integrate something like that ToG & Terayon thumb generator in it and use it when "Use as gallery" (or something like that) is selected from the folder menu.

25

HFS ~ HTTP File Server / Feature Req: Utilizing thumbs.db for image gallery

« on: August 30, 2007, 02:08:43 PM »

Hello again..

Besides plain filesharing, I'd say hosting image (& video) gallery is one thing many people would like to be able to use their HFS for. They could just drop their image folder into HFS, select 'Gallery' option and a gallery with thumbnails would be shown instead of the normal file listing. Currently I've used XnView to generate web page with thumbs and hosted it on my HFS but this requires _a lot_ of work and it's almost impossible for a novice to do.

So if HFS could simply read (and maybe also generate if not exist) normal windows thumbs.db files and use images inside them as thumbnails on generated web page.

Of cource HFS could have it's own thumbnail generator but I think that would require tons of more work and would be slow & heavy feature. Getting the thumbs from thumbs.db is quite fast and simple operation I believe..

Gallery could be very simple one (f.ex: http://uri.fi/xnviewgalleryexample/) but of cource it would be nice to have also template tags available for image resolution, dpi, exif infos etc. like in xnview does but that's not important really...

26

Bug reports / Re: minimize to tray when clicking close [x] button

« on: July 25, 2007, 05:45:54 PM »

Works OK here too..

27

HFS ~ HTTP File Server / Re: About "Don't consider as a download"...

« on: July 24, 2007, 07:50:18 PM »

HFS will show only 1 "thumbs" folder, and you will be able to set the don't log in the VFS itself.
try it with this new build www.dovedove.it/hfs/hfs123.exe

Great, I'll give it a try.. Although it requites a bit work since there is a few of these images folders but I think I'll manage.

28

HFS ~ HTTP File Server / Re: About "Don't consider as a download"...

« on: July 24, 2007, 02:15:04 PM »

That's a good fix for this situation too...I'll have to think about it..

29

HFS ~ HTTP File Server / Re: About "Don't consider as a download"...

« on: July 24, 2007, 10:26:39 AM »

maybe it should not be counted in the total since it's hidden.
do you agree?

You mean that Hits from a hidden subfolder would not be added to Hits of the main folder? I'd say that's quite a good idea. At least it would fix this situation. But I'd still like that "Don't consider as a download" to really do what it is titled. So it would not add those hits to folder hits nor total hits.

there is a "don't log" for this.

I can't set this since the images folder and the thumbs folder in it are both real folders. So I could set "don't log" for the images folder, but then it would not log the loading of the main images or the thumbnail page. It should be "don't log (mask)" so it could be used.. Maybe there could be a setting in "Log what" titled "Don't log files not considered as downloads".

30

HTML & templates / Re: welcome screen/search

« on: July 24, 2007, 10:02:24 AM »

Ok...I just tought that filelist link was not recursive by default but it was just my template...