Now that FileField is part of Drupal 7, the FileField Meta module included with FileField is without a home. Considering almost all sites will be using File module in Drupal 7, it would make sense for getID3 to provide integration with the core module and take advantage of the new FileAPI hooks. Since the FileAPI is nearly identical to the APIs provided by FileField in Drupal 6, we'd essentially need to simply rename the functions and include it in getID3. This would immediately provide getID3 module with Views integration, Token integration, and make ID3 information available immediately upon every call to file_load($fid).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

davebv’s picture

+1

drewish’s picture

I'm all for it.

RobLoach’s picture

Makes sense!

aaron’s picture

this is an awesome idea!

klonos’s picture

subscribing...

srgk’s picture

would be very cool

drewish’s picture

Status: Active » Needs work
FileSize
12.87 KB

Started this as part of the D7CX sprint. No provisions are made for an upgrade path. I haven't gotten around to doing the ID3 tag part since I'm thinking I want to make some changes.

drewish’s picture

FileSize
14.02 KB

Fixed a bunch of stuff. Can't figure out how to get the views support into the patch.

drewish’s picture

Status: Needs work » Needs review
FileSize
27.4 KB

this is getting towards close enough to commit. the whole id3 tag (title, artist, etc) is omitted but the view and token stuff seems to work.

quicksketch’s picture

Sweet, nice work drewish. Is there a reason for needing to comment out the tag logic from this patch? The same thing is already working AFAIK for FileField, I don't think it needs any special consideration for D7.

drewish’s picture

I think we can do better in D7. I'd like to explore a sub-module that allows tags to be mapped to CCK fields and allows reading and writing of the tags. Basically I'm trying to kill off the audio module and need to figure out a way to allow users to edit id3 tags on files.

drewish’s picture

I think we can do better in D7. I'd like to explore a sub-module that allows tags to be mapped to CCK fields and allows reading and writing of the tags. Basically I'm trying to kill off the audio module and need to figure out a way to allow users to edit id3 tags on files.

kjv1611’s picture

If this does end up working, is anyone going to be able to offer any sort of "tutorial" or step-by-step instructions on how to use this setup in place of the audio module? I know I'd like to be able to move my church's site to Drupal 7, and the audio module has been a key factor there - whether it or some replacement is workable - or works at least as well as the audio module.

Sounds like it's progressing well, so from a bystander point of view, it sounds good to me. :0)

yngens’s picture

subscribe

AdrianB’s picture

Subscribing.

Tunox’s picture

woohooooo!! great idea Nate

I can feel soon we might be able to build out of D7 and this module a lovely audio jukebox.
About time to let Jinzora fade away and retire itself.

mthart’s picture

subscribe

mthart’s picture

+1

bomarmonk’s picture

Subscribe...

JohnAlbin’s picture

FileSize
27.95 KB

I re-rolled the patch in #9 to apply to the current master branch. And then noticed a path error in hook_help().

We need to create a new 7.x-1.x off the tip of master (git co master; git co -b 7.x-1.x;) and then apply this patch via git am < 780848-20-getid-d7.patch. Oh, and then you'll need to edit the 7.x-1.x-dev release node to make it point at the new branch.

JohnAlbin’s picture

Status: Needs review » Needs work

Ok, pushed a new 7.x-1.x branch from the old master branch and updated the 7.x-1.x-dev release node to use the new branch instead of master.

Then I committed the patch in #20 to a new feature branch called: 780848-merge-filefield-meta

Since I haven't tested the patch and comments #10 and #11 show the patch needs more work, I didn't want to commit the patch to 7.x-1.x.

If you want to help test this, you can follow the instructions here to checkout a copy of the work from Git: http://drupal.org/node/173580/git-instructions/780848-merge-filefield-meta

harriszrashid’s picture

+1

Steven Jones’s picture

subscribe.

jthomasbailey’s picture

Tried #21 and got:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'blah.getid3_meta' doesn't exist: SELECT * FROM {getid3_meta} u WHERE u.fid IN (:fids_0); Array ( [:fids_0] => 3 ) in getid3_file_load() (line 183 of blah/sites/all/modules/getid3/getid3.module).

I ran updates, it didn't create a new table. Am I supposed to do that by hand?

I'm confused about the id3 module... if it doesn't work with Views or Token then what good is it? Could be there's a setting I'm missing but it doesn't seem to do anything at all.

ericduran’s picture

Status: Needs work » Needs review
FileSize
1.61 KB

So on the 780848-merge-filefield-meta branch the version detection is broken.

This patch fixes it to be inline with the way the latest 7.x-1.x-dev version of the module does it.

I made it a git format-patch so git knows the branch it belong to :)

This patch is against the 780848-merge-filefield-meta branch.

ericduran’s picture

FileSize
765 bytes

So as mention in #24 the table isn't created if you're coming from the dev version.

This patch adds an update hook to create the getid3_meta table.

I can imaging is annoying to upload different patches in the same issue, but it seems like everything related to the 780848-merge-filefield-meta branch is being kept here.

Do we instead maybe want to create a new component so we can tag the fieldfield-meta related issues with that component or maybe even a tag and keep the issues separated?

Until I hear back I'll just keep posting them here.

This is the patch to add the update hook.

ericduran’s picture

Ok and I think this is going to be the last patch needed.

This is another update hook for populating all the database from files that have already been created.

Just to reiterated. Each of my last three patches are different and solve a different issue within the 780848-merge-filefield-meta branch.

ericduran’s picture

One more.

Note all these patches for now need to be applied in the same order I'm uploading them.

This fixing the schema to allow up 13 characters. Because getid3 something returns join stereo which doesn't fit in the previous 10 char limit.

ericduran’s picture

Ok, Yet another one.

Sorry for the ridiculous amount of noise I'm making. I just keep running into each one of these issues one by one.

This patch fixes the views duration handler. Before it was assuming we'll get a proper timestamp and then formatting it with date. This is instead the value in seconds. So I'm doing the formatting by dividing the appropriate number. This patch might actually be incorrect because I'm confused as to how :minutes is supposed to be render, I'm not sure if it means total minutes, of minutes pass the hour.

Anyways here's the patch that makes at least the seconds and hours format work properly.

ericduran’s picture

After these patches get apply, I think the separate branch should probably be merged into the 7.x-1.x if not maybe even a 2.x branch :) (pretty please)

ericduran’s picture

Lol ok this will be my last patch for the day.

This fixes the minutes, and seconds views handler to work like it used to work in D6. I did switch it to use math because I ran into issues using the date function when the TimeZone is not set to UTC.

Again just to reiterate all these patches are git format-patch patches so they need to be apply in the correct order.

Each one of them fixes a different issue.

This should be good for now. :)

drewish’s picture

Eric you've got commit. Play nicely.

klonos’s picture

I think this might indeed deserve a 7.x-2.x branch.

ericduran’s picture

Thanks Andrew. I went ahead an push my patches up to the 780848-merge-filefield-meta branch.

I'll like to branch of to a 7.x-2.x branch but I'll wait and see what the other maintainers think. Also I want to do more testing see if I can find any more bugs.

If I find more issues I'll probably open separate issues for them as this thread if getting a bit confusing.

Maintainers:
- Should we open another branch 7.x-1.x-dev that has this filefield-meta work?
It seems like the correct approach to me, since this is a lot of work for a point release :)

I wont take any actions until I hear back from other people.

rickvug’s picture

Happy to see this happen! The new branch is looking a great improvement.

That said I'm wondering out loud if it should be responsibility of GetID3 to store the meta data for files. What if a developer wants to store additional values from FFMPEG or the Exif data from an image? It would be helpful to have all of this data saved centrally and available via a single API that is separate from metadata extraction. I know that this is the case now that I'm starting to look into using length, width and height in JW Player module.

I found the File Metadata project (http://drupal.org/project/file_metadata) which looks very promising for this role. However there hasn't been any development for a while (#806252: Status of File Metadata module). It has a single table with columns for fid, key, value, and the module providing the data. The structure should be more flexible as columns won't need to be created for new fields that users may want to add?

Any thoughts? I don't want great to get in the way of good but now feels like a good time to work this out seeing as how there's not yet a real 2.x branch.

rickvug’s picture

Looking at the getID3 code, File Metadata would need to add a table to store information such as human name and description for Token integration and any other user facing purpose. Something like:

module: getid3
name: audio-channel-mode
human_name: Audio channel mode
description: The number of channels in the audio, by name: stereo or mono.

I've never coded views integration and I'm not sure how the formatting could be done in a generic way for each key (perhaps that would still be the responsibility of getID3?). Sorting and filtering feels like something that could be implemented systematically since the data structure would be consistent for all values.

ericduran’s picture

@rickvug I see your point. The problem I see right now is that the only meta-data extraction happening right now is on getid3. If there were a couple of other modules doing the same thing it would make sense to have a separate api, but right now there isn't :-/

maybe when the file_metadata module gets some more traction we can merge them all in not really sure :-/

rickvug’s picture

@ericduran Sorry for the delayed response. All I have to say is that I completely agree. :) A file meta data API makes a ton of sense but let's not let that stop this issue. If the file_metadata module matures and other projects get on board then the transition could be re-evaluated later

ericduran’s picture

I've been using the separate branch and I think is time to merge it into the -dev channel and mark this ticket closed.

Anyone has any objection?

oriol_e9g’s picture

Yeah! Go go go!

rickvug’s picture

No objections here either. +1

matt_paz’s picture

I'm happy to start testing this week ...

elBradford’s picture

Me too, let's get this in dev! (that's what it's for, right?)

Edit: I found (maybe) 3 issues after cloning the 780848 branch:

  1. There's a php warning about separators when setting the File fields in views. My filefield (mp3) can have unlimited values and I'm guessing they're not being handled properly? For example when just displaying the file in views it will give me options on how to separate the multiple values, however the new fields added by this branch don't. Just a guess.
  2. My getid3_meta field wasn't populated, though the update process took some time and pegged my cpu. Consequently, when displaying the different metadata they were all 0 or empty
  3. I didn't see a value for things such as Artist or Track Title. Am I missing something?

I rolled back to stable because this isn't vital to me. Hope this information helps.

drett’s picture

Has there been any more action on the dev branch? I'm desperate to have this functionality. Thanks!

klonos’s picture

...unfortunately there haven't been any commits in dev since August 2011 :/

[edit] ...ok there's the 780848-merge-filefield-meta branch and there were a few commits back in February, but no action after that.

Nels’s picture

Using this commit, getID3 seems to be working as I expect/need it. Since I'm only using Duration (all the other data I need is in fields already), there could be problems in other aspects.

Thanks!!

juampynr’s picture

This work is already in branch 780848-merge-filefield-meta. @ericduran, could you create a new release?

ericduran’s picture

Status: Needs review » Fixed

This branch is now merged into the 7.x-1.x branch.

This is now closed.

I know of a couple of projects using this. I'll get some feedback after they start using the dev and if everything is good.

We can probably push a 7.x-1.1

Thanks all for the reviews, commits, comments, testing, etc...

--
http://drupalcode.org/project/getid3.git/commit/3b3b8a4

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.