showfed datastream display problem

Project:RUcore dlr/EDIT
Version:7.0.1
Component:Code
Category:bug report
Priority:normal
Assigned:triggs
Status:closed
Description

The following two objects on rep-devel do not display the
same number of datastreams in a search result and in the
showfed display.

rutgers-lib:25475
Search result shows FLV-1, MOV-1
showfed just FLV-1

rutgers-lib:201060
Search result shows PDF-1, MOV-2
showfed just PDF-1

dh:lynx
"http://rep-test.libraries.rutgers.edu:8080/fedora/objects/rutgers-lib:2547
5/datastreams/MP4-1?dsLabel=MP4-1&logMessage=dlr/EDIT+user+changed+label"
dh:lynx
"http://rep-test.libraries.rutgers.edu:8080/fedora/objects/rutgers-lib:2010
60/datastreams/MP4-2?dsLabel=MP4-2&logMessage=dlr/EDIT+user+changed+label"

These were part of the 17 errors from the backlabels project on rep-devel, but it
maybe more widespread than just these two examples.

Comments

#1

Thanks Dave. I'll look into this one.

#2

At least the MP-4 issues are a matter of bad data in the objects. These two objects have MP4 test datastreams with the mimetype simply "mp4" rather than "video/mp4", which causes the Fedora process to fail. I changed the mimetype on these two datastreams to video/mp4 and was then able to change the labels. The other issue is a bit different. I'm looking into that.

#3

Assigned to:triggs» dhoover
Status:active» test

Good bug Dave! Thanks! It should be fixed now.

#4

Assigned to:dhoover» triggs

The order of the datastreams is fixed.

I believe the bad mime type can also be seen on a number
of the failed records from the backlabels run. In particular
if you look on rep-devel at /tmp/dh there is a list
of the ones that failed and if you follow them into fedora
you will see what i mean.

Mainly it seems like ones that are for PDF files and list
the MIME type as PDF . I only mention this because you
fixed the mp4 ones.

Of the 18 that failed backlabels (see /tmp/dh on rep-devel)
these are the MIME types

<td align="left">application/pdf</td>
<td align="left">application/pdf</td>
<td align="left">application/pdf</td>
<td align="left">image/jpeg</td>
<td align="left">application/pdf</td>
<td align="left">application/pdf</td>
<td align="left">application/pdf</td>
<td align="left">PDF</td>
<td align="left">video/mp4</td>
<td align="left">PDF</td>
<td align="left">PDF</td>
<td align="left">PDF</td>
<td align="left">PDF</td>
<td align="left">PDF</td>
<td align="left">application/zip</td>
<td align="left">application/zip</td>
<td align="left">application/x-spss-por</td>
<td align="left">video/mp4</td>

#5

Sorry that should have read the same datastreams are now displaying
for both search results and showfed

#6

The mimebacklabels.php script now looks for PDF as a bad mime in addition to empty and unknown and changes them before attempting to change the labels.

#7

Display problem is fixed.

Jeffery,

There may be other invalid mimetypes. How do you plan to identify and fix them? Is it possible to identify invalid mimetypes in a systematic manner?

Thanks,
KA

#8

The main issues have to do with mime types given as "unknown" and simply "PDF" or "MP4". backlabels now checks for these. We could create a test of the mime types on all the datastreams and fix them if necessary.

#9

Status:test» closed

Closing this bug. I am ignoring the mime type comment since it is another issue.

Back to top