[Beltxo]

Look like 2 differents approachs to the same problem. Or not?

The options with SF plugin are so different than with Cybermutant one.

[SlugFiller]

Quote

The options with SF plugin are so different than with Cybermutant one.

Well, both have the same purpose, after all.

Only difference is in the implementation. I've tried to match my quality with the rest of the VLC source code. I've done my best to keep the library multi-platform, even maintaining byte-order correctness, though I haven't actually tried to compile it for linux, so I can't be sure if I've succeeded.
I've also put all of the error handling expected from a linux-styled library. It is guaranteed to be as stable as the rest of VLC allows it to be.

As stated above, the other plugin doesn't even begin to compile on linux. That's 'nuff said, right there.

[starbuck28]

Hi SlugFiller,

I was able to compile vlc and your metfile plugin successfully without errors on linux.
(great work SlugFiller!!!)

The appropriate file libaccess_metfile_plugin.so is in the vlc module dir
/usr/lib/vlc/access/

Now when I start vlc the plugin did not show up under the access plugins in the options menu...

How could I determine if the plugin was loaded?

Is there any linux user who got this working?

Any suggestions?

best regards
starbuck

[SlugFiller]

Hmm... I used to have a similar problem, but the issue was actually that I didn't know how to tell MinGW to compile a Win32 DLL(As opposed to a Dos EXE with a ".dll" extension), so I doubt you have the same issue.

Are you sure you are placing the plugin correctly? Perhaps there's somewhere else it has to be configured?(Some /etc file you need to edit, or something)
As far as I know, if it's working, it should appear in the menus.

I sure hope you get it to work.

[starbuck28]

Hello,

My next step is to compile vlc with the enable-debug option.

So I hopefully could figure out what's wrong with plugin.

With the debug version and output I think I am able to determine
if the plugin was loaded at all!

best regards
starbuck

[Beltxo]

SlugFiller, on Sep 27 2005, 04:22 PM, said:

Quote

The options with SF plugin are so different than with Cybermutant one.

Well, both have the same purpose, after all.

Only difference is in the implementation. I've tried to match my quality with the rest of the VLC source code. I've done my best to keep the library multi-platform, even maintaining byte-order correctness, though I haven't actually tried to compile it for linux, so I can't be sure if I've succeeded.
I've also put all of the error handling expected from a linux-styled library. It is guaranteed to be as stable as the rest of VLC allows it to be.

As stated above, the other plugin doesn't even begin to compile on linux. That's 'nuff said, right there.

Hmmm... I am not talking about inner quality or cleaness of code. Just about functionality.

With your version:

- I can't enable/disable the plugin for AVI or MPEG. I don't want it for AVIs 'cause it allways fails more or less [both plugins]

- I can't enable/disable "make seekable stream", that it is sometimes needed to work smooth.

- AVI files crashes VLC when coming to the first gap.

...

So your plugin could be so good and pretty coded, but on the "user side" of it... well, I don't find it to fill my expectatives.

Take all this as a possitive critic, just some thoughts and all that stuff...

This post has been edited by Beltxo: 29 September 2005 - 10:58 AM

[SlugFiller]

Quote

I don't want it for AVIs 'cause it allways fails more or less [both plugins]

Use gap-mode 1 in mine. Avi mode(aka "seekable stream") in the other.
Works perfectly for me.

Quote

- I can't enable/disable "make seekable stream", that it is sometimes needed to work smooth.

Gap-mode 1 for seekable avi. 0 for streaming mpeg. 2 for max compatibility, minimal skip.

Quote

- AVI files crashes VLC when coming to the first gap.

They work fine for me on my plugin. I usually alternate between gap-mode 0 and 1, depending on the file.

I technically offer the same option, but I unify them under "gap mode". Beyond that, there is nothing to be offered without delving into the specifics of the wrapper and codecs used, and the wrapper and codecs handlers already take care of that.

To summarize:
0: Remove gaps, crop file.
1: Auto-seek past gaps. Removes gaps, but keeps index for seekable avi files.
2: Replace gaps with 0-filled sections. Max compatibility mode.

[Beltxo]

Thank U for the info SlugFiller!

Maybe, that settings info should be in a text file within the plugin pack.

[SlugFiller]

You can get it on tooltip if you place your mouse over the scroll for a second.
You might try that with some of VLC's other options, though from my experience, linux devs, with all their coding might, seem to crash and burn when it comes to documentation.

[Beltxo]

SlugFiller, on Sep 29 2005, 10:27 PM, said:

You can get it on tooltip if you place your mouse over the scroll for a second.
You might try that with some of VLC's other options, though from my experience, linux devs, with all their coding might, seem to crash and burn when it comes to documentation.

So... wich would be the optimal VLC settings for the plugin to run at its best?

[SlugFiller]

It's file dependant. I usually find my soft-spot through trial-and-error, though gap-mode 1 seems to work okay for most file.
For AVI files, there are also a few options in the AVI decoder plugin, such as index rebuilding, etc. Trial-and-error works best there as well.

[QQ]

SlugFiller, how can I know if file is read via metfile plugin? I mean, if I open the .met file, then I'm somewhat sure it is, but if I open it via preview in emule, then it passes .part file, I think, and I'm not sure it uses your plugin then.. does it?

[SlugFiller]

The plugin is set to load prior to the normal file plugin. It then scans the loaded file to see if it is a met file, then, if it fails, it attempts to add ".met" to the filename and look for a matching met file, and if that doesn't work it surrenders and allows the normal file plugin and other plugins to take over.

If you really want to make sure the met plugin loaded, just open the messages log. It should give some verbose at load time indicating the plugin was loaded.

[starbuck28]

Hi SlugFiller,

I have managed to compile the metfile-plugin + vlc with debug-option
enabled.

Now when I start vlc I get the following messages:

[00000001] main vlc debug: recursively browsing `modules'
[00000001] main vlc warning: cannot load module `modules/access/libaccess_metfile_plugin.so' (modules/access/libaccess_metfile_plugin.so: undefined symbol: _fullpath)

Now it is clear why the plugin is not loaded and did not show up in the module list.

What does this mean: undefined symbol: _fullpath) ?

Can you explain this and possibly fix it?

regards
starbuck

This post has been edited by starbuck28: 03 October 2005 - 08:26 PM

[SlugFiller]

I've used _fullpath and other run-time functions in MergePath in order to resolve relative paths.
However, now that I look over it, it seems that these may be MS specific(there's an example of MinGW being MS-compliant for you).

It seems the standard version of "_fullpath" is "realpath". The syntax is slightly different:
_fullpath(dest, src, FILENAME_MAX);
becomes:
realpath(src, dest);

I couldn't find equivalents for the other run-time functions I use in MergePath. Hopefully, they would work as they are. If not, you will have to find equivalents in the run-time library you are using.

[starbuck28]

@SlugFiller

Thank you for this information
You are right.
The functions _fullpath, _splitpath, stricmp and _makepath are Micro$oft specific and not available/incompatible with the gcc compiler.

Regarding this issue I send you a PM about my thoughts how to solve this problems.

It would be fine when you could look at my suggestions.
I would like to get this *damn good* partfile plugin module working on linux!

PS: Oh now I saw that I have broken your first rule ... Sorry for that
SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.

I hope you will read it anyway.

This post has been edited by starbuck28: 04 October 2005 - 07:59 PM

[SlugFiller]

Read your PM(which you could have just as easily posted here, see rules #3 and #4). Here are my notes:

The second call to realpath should be:

return realpath(path, malloc(PATH_MAX));

Actually, I'm not sure whether even this would work, since the man pages describle realpath as taking an array as the second parameter.
The MS version is definately more dev-friendly. Too bad it's MS-only(can't believe I just wrote that).
If the above doesn't work, use another local array and strdup it.

Also, I've looked at the use of stricmp. It's unneeded in the linux version, you can just cut that part out, since there are no drive letters in linux. This is to avoid the case where "dest" is an absolute path pointing to a drive other than that of "source", which would cause the end result to point at the right folder on the wrong drive. Linux has no drives so the whole check is unnecessary.
Actually, I'm not even sure as to how linux would react to "/dev/hda1/emule/temp/.//dev/hda2/parts/001.part".

As for _splitpath and _makepath... Hell, I dunno.

Maybe MergePath needs to be rewritten from scratch. The only reason I've used run-time calls in the first place is because I was aiming for multi-platformness. Otherwise, I would have just written a path string-parser.

Merge path was simply supposed to turn:
* source="c:\eMule\001.part.met", dest="001.part" -> return strdup("c:\eMule\001.part");
* source="\eMule\001.part.net", dest="..\.\001.part" -> return strdup("c:\001.part");
* source="c:\eMule\001.part.net", dest="c:001.part" -> return strdup("c:\eMule\001.part");
* source="c:\eMule\001.part.net", dest="d:001.part" -> return strdup("d:001.part");
* source="c:\eMule\001.part.net", dest="\001.part" -> return strdup("c:\001.part");
* source="eMule\001.part.net", dest="..\..\001.part" -> return strdup("..\001.part");

It's easy to see that the above can be achieved with a simple string parser. However, the above examples only apply for Windows. In linux, for example, "\" is a valid part of a filename, and only "/" acts as a directory changer. Also, drive letters do not exist in linux.
I was hoping to make a universal solution through the use of run-time functions, but I didn't expect said functions to be themselves OS-dependant.

If you find a different, more multi-platform, solution, let me know.
But for making a linux-only compilation, I just suggest replacing all of it with a linux-only parser.

[starbuck28]

Ok I agree with you... attached the PM so the other visitors of this
thread know what we are talking about...

Quote

Hi,

thanks for your information.

Upon your suggestion I looked at the code and changed the _fullpath function
to realpath.

static char* MergePath( const char* source, const char* dest)
{
        char path[FILENAME_MAX];
        char drive1[FILENAME_MAX];
        char drive2[FILENAME_MAX];
        char dir1[FILENAME_MAX];
        char dir2[FILENAME_MAX];
        char filename[FILENAME_MAX];
        char fileext[FILENAME_MAX];

        drive1[0] = drive2[0] = 0;

        realpath(source, path);
        _splitpath(path, drive1, dir1, NULL, NULL);
        _splitpath(dest, drive2, dir2, filename, fileext);
        if (!drive2[0] || !stricmp(drive1, drive2)) {
                char dir[FILENAME_MAX*2+2];
                strcpy(dir, dir1);
                strcat(dir, "./");
                strcat(dir, dir2);
                _makepath(path, drive1, dir, filename, fileext);
                return realpath(NULL, path);
        }
        return strdup(dest);
}

Is this right? -> return realpath(NULL, path);  ?

[I learned C in school but long time ago I wrote my last c app ...
So it is possible not to get the point first... Please excuse this
I have to do more coding to get "back in business" ]

Okay this one solved the problem but more to come.

Please note: With linux mostly gcc is used as compiler.
On my box (SuSE 9.3) for example runs gcc version 3.3.5
If gcc can compile the code without errors it should run on every linux box.
Now I think it is the best way making the code multi-platform capable as you
mentioned it before. It should compile under linux and windows the same way.

But now back to the topic.

gcc complains about the use of functions stricmp
The error message is, 'implicit declaration of
function.'

I assume this means that this is a function that Microsoft
added to the language?? 
stricmp is a case-INsensitive compare I found out.

stricmp is problematical. It's not a standard function, you see.

The most obvious solution to the problem is to roll out our own function


Here's my starting point:

int cmpistr(const char *s, const char *t)
{
  int diff = 0;

  /* some checks here for s and t being non-NULL
   */

  while(*s != '\0' && toupper(*s) == toupper(*t))
  {
    ++s;
    ++t;
  }
  if(*s != '\0' || *t != '\0')
  {
    diff = (*s < *t) ? -1 : (*s > *t);
  }
  return diff;

}

I took the easy way out:

#define stricmp strcmp  (but then it is without case-INsensitive compare )

But in this case  stricmp only exist once so we can change it to strcmp.
Is it a problem when it is not a case-INsensitive compare?

What do you think?

_splitpath and _makepath is next ...

[00000001] main vlc warning: cannot load module `modules/access/libaccess_metfile_plugin.so' (modules/access/libaccess_metfile_plugin.so: undefined symbol: _splitpath)

I suppose splitpath() and makepath()  isnt available with GCC!

To solve this what do you think about the following code:

// *******************************************************************
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

// Abstract:      split a path into its parts
// Parameters: Path: Object to split
//                    Drive: Logical drive , only for compatibility , not considered
//                    Directory: Directory part of path
//                    Filename: File part of path
//                    Extension: Extension part of path (includes the leading point)
// Returns:      Directory Filename and Extension are changed
// Comment:   Note that the concept of an extension is not available in
//                   Linux, nevertheless it is considered

void _splitpath(const char* Path,char* Drive,char* Directory,char*
Filename,char* Extension)
{
  char* CopyOfPath = (char*) Path;
  int Counter = 0;
  int Last = 0;
  int Rest = 0;

  // no drives available in linux .
  // extensions are not common in linux

  // but considered anyway
  Drive = NULL;

  while(*CopyOfPath != '\0')
    {
      // search for the last slash
      while(*CopyOfPath != '/' && *CopyOfPath != '\0')
        {
          CopyOfPath++;
          Counter++;
        }
      if(*CopyOfPath == '/')
        {
          CopyOfPath++;
         Counter++;
          Last = Counter;
        }
      else
          Rest = Counter - Last;
    }
  // directory is the first part of the path until the
  // last slash appears
  strncpy(Directory,Path,Last);
  // strncpy doesnt add a '\0'
  Directory[Last] = '\0';
  // Filename is the part behind the last slahs
  strcpy(Filename,CopyOfPath -= Rest);
  // get extension if there is any
  while(*Filename != '\0')
  {
    // the part behind the point is called extension in windows systems
    // at least that is what i thought apperantly the '.' is used as part
    // of the extension too .
    if(*Filename == '.')
      {
        while(*Filename != '\0')
        {
          *Extension = *Filename;
          Extension++;
          Filename++;
        }
      }
      if(*Filename != '\0')
        {Filename++;}
  }
  *Extension = '\0';
  return;

}

// Abstract:     Make a path out of its parts
// Parameters: Path: Object to be made
//                    Drive: Logical drive , only for compatibility , not considered
//                    Directory: Directory part of path
//                    Filename: File part of path
//                    Extension: Extension part of path (includes the leading point)
// Returns:      Path is changed
// Comment:   Note that the concept of an extension is not available in
//                   Linux, nevertheless it is considered

void _makepath(char* Path,const char* Drive,const char* Directory,
       const char* File,const char* Extension)
{  
  while(*Drive != '\0' && Drive != NULL)
  {
    *Path = *Drive;
    Path++;
    Drive++;
  }
  while(*Directory != '\0' && Directory != NULL)
  {
    *Path = *Directory;
    Path ++;
    Directory ++;
  }
  while(*File != '\0' && File != NULL)
  {
    *Path = *File;
    Path ++;
    File ++;
  }
  while(*Extension != '\0' && Extension != NULL)
  {
    *Path = *Extension;
    Path ++;
    Extension ++;
  }
  *Path = '\0';
  return;

}

Note: Here it may be useful to use a #ifdef directive for the linux functions
and the appropriate existing windows  version of these functions !


It would be fine when you could look at my suggestions.

I would like to get this *damn good* partfile plugin module working on linux

So long

starbuck28

This post has been edited by starbuck28: 04 October 2005 - 10:21 PM

[Janek Szymczak]

soebody speak to me

[PacoBell]

Janek Szymczak, on Oct 12 2005, 04:06 PM, said:

soebody speak to me

Uh, hi. I noticed that all of your posts so far on this board have been roughly the same overall. Now that introductions are out of the way, would you like to say something else?