Results 1 to 17 of 17
  1.    #1  
    Regarding SFTP picture (jpg) to /media/internal/DCOM/100PALM folder that is less than 100K or larger than 100K.

    I did the following test:

    If I SFTP via WiFi a 100K plus JPG file to the 100PALM folder, then the Photo application will not see the picture. If I do the same and the file is less than 100K the Photo application has no problem recognizing the picture.

    If I USB via cable the same 100K plus JPG file to the 100PALM folder, then the Photo application have no problem with recognizing the picture.

    If I SFTP via WiFi the same JPG file and I rename in under USB control, the Photo application see the JPG file.

    If I SFTP via WiFi the same JPG file and I start Putty where I sudo myself to root and I change the mount to remount,rw. From here I rename the file in the hope that it would do the same as if I had renamed the file under USB control; however this does not work, meaning that the Photo application does not recognizing the picture.

    So the two big questions are: Why is there a difference in SFTP a smaller (less than 100K) JPG compare to a larger (greater then 100K) with regards to what the Photo application can recognizing? The Second question is what is the difference between USB connecting via a cable and the SFTP via WiFi when it comes to what the Photo application can recognizing?

    Anybody have an input here?
  2.    #2  
    I am not sure what is going on, except that some rights / authentication / permissions is to blame for the WiFi SFTP issues when pictures are loaded to the Pre but not seen by the Photo Album application.

    I login to the Pre via Wifi and SFTP and navigated to the /media/internal/DCIM/100PALM/ folder. I created a new folder under the 100PALM folder and uploaded several pictures to the new folder. Some of the uploaded pictures where less than 100Kb in size and others where above 3Mb.
    Then I exit the SFTP program and ran the Photo Album application, no surprise the Photo Album did not see the new Album and the new picture (see earlier postings).

    I have Internalz downloaded so I pointed it to the new folder, renamed the folder and now when I start the Photo Album application I not only see the new folder as a new Album but also displayed the picture no matter the image size.

    Anyone have an idea what the difference is between connecting via USB cable and Wifi SFTP connection and then what rights / authentication / permissions the Internalz works on please let me know.
  3. APEowner's Avatar
    Posts
    85 Posts
    Global Posts
    86 Global Posts
    #3  
    This is interesting. I've been lurking and mirroring your progress on this thread http://forums.precentral.net/web-os-...manager-3.html and I'm at the same place you are. I can SFTP through WiFi and I'm seeing the same image size issue. Here's some further information for us to digest.

    I used Terminal to rename the new folder and Photo Album was not able to see it. I connected via USB and renamed the folder again and Photo Album was able to see both the folder and the images in it regardless of size. I then switched back to SFTP access and added another file that Photo Album was not able to see. When I use the ls -l command to look at the permissions they're the same on both the images I can see and the ones I cannot.
  4.    #4  
    APEowner, thanks for the input. It seems to me that more research is needed and it may have to do with rights / authentication / permissions regarding Folder or Files. However there is an exception that smaller files (under 100Kb) does not have the issue and that does not point to rights / authentication / permissions.
  5. APEowner's Avatar
    Posts
    85 Posts
    Global Posts
    86 Global Posts
    #5  
    I've done a little bit more digging and research and I may have something. Keep in mind that I'm an embedded programmer who works primarily in C so I don't really know what I'm talking about when we get to Linux and Javascript. It appears that Linux uses some sort of file index system and we may be bypassing that when we access file through SFTP. In this thread: http://forums.precentral.net/webos-p...urces-etc.html Jason Robitaille says.

    I use an alternate method for Internalz that forces a rescan.

    Stop fileindexer process, delete media.db3, and start fileindexer. Then it starts and notices the db3 missing, it rebuilds it, rescanning /media/internal/
    when talking about ways to get the system to rescan the /media/internal/ directory. I don't really know what to do with that information but it may be a clue. Also, if I'm on the right track here I don't know why the smaller files would show up.
  6. #6  
    Quote Originally Posted by APEowner View Post
    I've done a little bit more digging and research and I may have something. Keep in mind that I'm an embedded programmer who works primarily in C so I don't really know what I'm talking about when we get to Linux and Javascript. It appears that Linux uses some sort of file index system and we may be bypassing that when we access file through SFTP. In this thread: http://forums.precentral.net/webos-p...urces-etc.html when talking about ways to get the system to rescan the /media/internal/ directory. I don't really know what to do with that information but it may be a clue. Also, if I'm on the right track here I don't know why the smaller files would show up.
    yes, it's possible it's a fileindexer issue.

    The webOS indexes all files in /media/internal/ and saves the info to a sql database for later use by things like Photos/Music/Videos app and for devs with the file chooser widget. However it doesn't recognize file changes/additions under some circumstances.

    A way to get around this issue and force a rescan is either by manually deleting:
    Code:
    /var/luna/data/mediadb.db3
    or by moving/copying/renaming a file in Internalz (as FileMgr service will force the rescan in the process).
    If you've liked my software, please consider to towards future development.

    Developer of many apps such as: WebOS Quick Install, WebOS Theme Builder, Ipk Packager, Unified Diff Creator, Internalz Pro, ComicShelf HD, LED Torch, over 70 patches and more.

    @JayCanuck @CanuckCoding Facebook
  7. APEowner's Avatar
    Posts
    85 Posts
    Global Posts
    86 Global Posts
    #7  
    Thank you Jason. I thought you could add some insight to this issue. Here's some more food for thought.

    I deleted the mediadb.db3 file via SFTP and stopped and restarted fileindexer from terminal and all of the photos are now visible in the Photo Album regardless of file size or how they were put there.

    I'm thinking we need someone who's a better javascript programmer than I (which would be just about anyone) to do a file indexer rescan patch. Perhaps as a menu item in the Photo Album.
  8. #8  
    Quote Originally Posted by APEowner View Post
    Thank you Jason. I thought you could add some insight to this issue. Here's some more food for thought.

    I deleted the mediadb.db3 file via SFTP and stopped and restarted fileindexer from terminal and all of the photos are now visible in the Photo Album regardless of file size or how they were put there.

    I'm thinking we need someone who's a better javascript programmer than I (which would be just about anyone) to do a file indexer rescan patch. Perhaps as a menu item in the Photo Album.
    In my next update of FileMgr service, I can make the method public and make a patch, if that'd what you mean . Cause currently not possible with purely javascript
    If you've liked my software, please consider to towards future development.

    Developer of many apps such as: WebOS Quick Install, WebOS Theme Builder, Ipk Packager, Unified Diff Creator, Internalz Pro, ComicShelf HD, LED Torch, over 70 patches and more.

    @JayCanuck @CanuckCoding Facebook
  9. APEowner's Avatar
    Posts
    85 Posts
    Global Posts
    86 Global Posts
    #9  
    I just had a further thought. Perhaps the correct solution would involve a change in the WebOS SFTP service so that it updated the fileindexer correctly.
  10. APEowner's Avatar
    Posts
    85 Posts
    Global Posts
    86 Global Posts
    #10  
    In my next update of FileMgr service, I can make the method public and make a patch, if that'd what you mean . Cause currently not possible with purely javascript
    That sounds like a functional solution. Is the fileindexer service a linux thing or is it unique to WebOS?

    Thanks again for your input and assistance with this.
    Last edited by APEowner; 11/12/2009 at 09:43 PM.
  11. #11  
    Quote Originally Posted by APEowner View Post
    That sounds like a functional solution. Is the fileindexer service a linux thing or is it unique to WebOS?

    Thanks again for your input and assistance with this.
    I believe it's a proprietary Palm webOS thing
    If you've liked my software, please consider to towards future development.

    Developer of many apps such as: WebOS Quick Install, WebOS Theme Builder, Ipk Packager, Unified Diff Creator, Internalz Pro, ComicShelf HD, LED Torch, over 70 patches and more.

    @JayCanuck @CanuckCoding Facebook
  12. APEowner's Avatar
    Posts
    85 Posts
    Global Posts
    86 Global Posts
    #12  
    I believe it's a proprietary Palm webOS thing
    That would further explain why file access through linux tools rather than WebOS APIs doesn't update it correctly. I wonder if the good folks over at WebOS Internals would consider a modification to the sftp server code that uses your trick to update that.
  13.    #13  
    Jason & APEowner, how do I re-run / re-start the webOS indexer and can I do so without having to delete the mediadb.db3 file?
  14. APEowner's Avatar
    Posts
    85 Posts
    Global Posts
    86 Global Posts
    #14  
    Jason & APEowner, how do I re-run / re-start the webOS indexer and can I do so without having to delete the mediadb.db3 file?
    Bjarn-I assume you mean manually and not programaticaly. I used Terminal which is available through Preware to enter the commands "stop fileindexer" and "start fileindexer". I deleted the mediadb.db3 file via sftp prior to stopping and starting the service. It's probably better to stop the service, delete the file and then start the service. Deleting the .db3 file is needed. What we're doing is forcing the fileindexer service to rebuild the database.
  15.    #15  
    APEower, I appreciate the information and yes I think I can do the "stop fileindexer" and "start fileindexer" from Putty (that can be called from within WinSCP). If I get time (I also have to uninstall patches and update to the new webOS 1.3.1 release, plus re-install the patches) this weekend I may even try (with some help from my girlfriend Shay that is a UNIX administrator) to create a script that will Stop, Delete and then Start the indexing job.
  16.    #16  
    So I upgraded to WebOS 1.3.1.

    OK before I did so I backed up the Pre and to be extra safe I uploaded to Google my contacts so I would not lose them.

    I removed all the patches before I restarted the Pre and was ready to upgrade to the new WebOS.

    The upgrade installed as expected and I restarted the Pre one more time.
    All my stuff was still there so I was ready to re-install my group of patches. After that I restarted one more time.

    Result: I am up and running and very happy. Yes I still have the WiFi large picture upload issue, but I have a hack for that (see posting above).

    What is not working at this time is that I can now not open images using the Internalz, but I am 100% sure that Jason is working overtime on this.

    More when I have more.
    Bjarne Winkler
    ---------------------------------------------------
    ==> Pre: There's a patch for that!
  17. #17  
    Any update on this? Is there a faster way than stopping the service, deleting the file and restarting the fileindexer service?

    Thanks!

Posting Permissions