Ticket #528 (assigned defect)

Opened 20 months ago

Last modified 20 months ago

broken .asx file

Reported by: Michiel.Schok Owned by: vandersluijs01
Priority: critical Milestone: MediaMosa 3.0
Component: Core Version:
Keywords: Cc:
MoSCoW: none Estimated time after impact analysis:
Related to project: none Tested: yes
Accepted: yes Estimated Hours: 0

Description

This is probably fixed in every release of MediaMosa to date.... And broken in the release thereafter.

When issuing a call like

<request_uri>[GET] asset/L1AQ9nuWVVKgGbCmTQk0cr2a/play?mediafile_id=w2LMHiQZsIgeXrNLwRAJNFl9&amp;user_id=urn:collab:person:surfnet.nl:michiel&amp;response=object&amp;start=5000&amp;duration=3000</request_uri>

the result is

    <item>
      <output>&#13;
&lt;object id='w2LMHiQZsIgeXrNLwRAJNFl9' classid='CLSID:22D6F312-B0F6-11D0-94AB-0080C74C7E95' standby='Loading Media Player components...' type='application/x-oleobject' width='720' height='544'&gt;&#13;
&lt;param name='filename' value='http://app.acceptatie.vpcore.snkn.nl/still/G1gtkPRWYYMpUfRUUYR6pXiT.asx' /&gt;&#13;
&lt;param name='autostart' value='true' /&gt;&#13;
&lt;embed type='application/x-mplayer2' src='http://app.acceptatie.vpcore.snkn.nl/still/G1gtkPRWYYMpUfRUUYR6pXiT.asx' autostart='1' name='w2LMHiQZsIgeXrNLwRAJNFl9' width='720' height='544'/&gt;&#13;
&lt;/embed&gt;&#13;
&lt;/object&gt;</output>
      <content_type>text/html</content_type>
      <ticket_id>G1gtkPRWYYMpUfRUUYR6pXiT</ticket_id>
    </item>

Great. But when we try to fetch the .asx file at  http://app.acceptatie.vpcore.snkn.nl/still/G1gtkPRWYYMpUfRUUYR6pXiT.asx a 404-not found is given.

Change History

Changed 20 months ago by forgacs

  • owner set to forgacs
  • status changed from new to assigned

Changed 20 months ago by forgacs

  • owner changed from forgacs to Michiel.Schok

Michiel,
We have fixed this issue in MediaMosa 3.0.7 and 2.3.18.

Changed 20 months ago by Michiel.Schok

I didn't know a fix for 2.3 was necessary. Current production release 2.3.13 is running great.

Changed 20 months ago by forgacs

It works fine for 2.3.13, because there is an apache setting for it on production.
Acceptation should work fine too, if you change the download server to:
 http://download.acceptatie.vpcore.snkn.nl/

Changed 20 months ago by vandersluijs01

I changed the download servers on acceptation to:  http://download.acceptatie.vpcore.snkn.nl

Changed 20 months ago by forgacs

  • owner changed from Michiel.Schok to vandersluijs01

Tom, If we want to use the download server on acceptation, then we should change the apache vhost settings on app1 and app2 for the download server. Please comment out this part (as it is in app vhost configuration).

        Alias "/still/" "/mnt/naspcd1/vpx-acc/still_links/"
        <Directory /mnt/naspcd1/vpx-acc/still_links/>
                Options -Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

Till that we will have problem to see the still images for acceptation.

Changed 20 months ago by forgacs

PS. I changed back the still server to app.

Changed 20 months ago by Michiel.Schok

Seems to me that 'staging', 'acceptatie' and 'productie' should follow the same configuration, so that the result of a test on either 'staging' or 'acceptatatie' is valid sign for the behaviour on 'productie' if that build gets deployed there.

Changed 20 months ago by vandersluijs01

The Alias "/still/" part is allready commented out in the app vhost on the acceptation servers. And the config is exactly the same as it is on production.

Changed 20 months ago by forgacs

I think the problem is in the "download" vhost file (on app1.acc and app2.acc).

Changed 20 months ago by vandersluijs01

When the vhost is changed i need to put the download servers to download.acceptatie.vpcore.snkn.nl again?

Changed 20 months ago by forgacs

Yes, please. Then we will do a check on acceptation.

Changed 20 months ago by Michiel.Schok

  • tested changed from no to yes
  • accepted changed from no to yes

Just rechecked this issue, and it seems fixed.
If that is due to some actions (Kennisnet, madcap, ZX), please document and close the ticket.

Changed 20 months ago by forgacs

Checked and seems ok.

Note: See TracTickets for help on using tickets.