So, I've finally gotten my avi->mp4 conversion script working as I'd like, but the problem now seems to be that mediatomb cannot stream my video for more than 5min at a time without crapping out. 1 of 3 things happens at this time, I get a "you do not have access to the media server" error message, a "corrupted data" message (data is not actually corrupted and can be replayed for a couple seconds before the message repeats, this is eventually followed by the "you do not have access" message, or the ps3 stops video and completely locks up forcing me to reboot (the ps3 cannot properly shut down during this and beeps 3x before finally turning off).
I recompiled with debugging turned on and don't see anything odd, but perhaps you can shed some light so I'll append a snippet at the end. On my side of things my ps3 is still only getting a 67% connection, so I'll tinker with getting it up higher and see if anything improves. Thanks in advance for any advice/help.
Yes Jin, the version I'm using is .10 and my problem seems pretty much independent of whatever I make the retry parameter. Regardless of whether it's a small (3) or large (50) value the error I describe arises, although I haven't seen a full system freeze in a while the view times seem to be diminishing and I'm not sure why. I've upgraded my wireless router's firmware and am now seeing a better connection, but like I said the problem still persists. Please let me know if there are any log entries you'd like to see or any clues I can give you as to why this is happening. Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tinkered with it more today to no avail. The only difference having the retry parameter seems to make is that rather than lock up my ps3, the file will report as corrupted data instead. My router is reporting the wireless connection to the ps3 as stable and the entire video file is only 78M so I don't think that would be the source of the problem. I wish I could provide more info, but any of the changes I've made seem to have little to no impact, other than restarting the mediatomb server seems hold off the errors for 4-5min.
Also, when the video does create a lockup situation the viewer page for mediatomb manages to lock up firefox as well until the process is killed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, then it is possible that you do not have the problem, for which this workaround parameter was created; maybe your problem is somewhere else...
A wireshark log could give us some clues, however I will be able to look at it next week when I return from holidays (my internet access here is rather limited)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you download the file from the server using wget? This would be the first test if largefile works at all.
You can simply copy the link to the item from the web UI, don't forget to put it in "quotes" in the shell
Second test would be to stream that file from MediaTomb using mplayer, just feed mplayer the same link as you used for testing with wget.
If that works, the problem will mostprobably be on the PS3 side, if that does not work we can start debugging.
I did a test with an 8GB DVD iso and mplayer was able to stream it without problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, I've finally gotten my avi->mp4 conversion script working as I'd like, but the problem now seems to be that mediatomb cannot stream my video for more than 5min at a time without crapping out. 1 of 3 things happens at this time, I get a "you do not have access to the media server" error message, a "corrupted data" message (data is not actually corrupted and can be replayed for a couple seconds before the message repeats, this is eventually followed by the "you do not have access" message, or the ps3 stops video and completely locks up forcing me to reboot (the ps3 cannot properly shut down during this and beeps 3x before finally turning off).
I recompiled with debugging turned on and don't see anything odd, but perhaps you can shed some light so I'll append a snippet at the end. On my side of things my ps3 is still only getting a 67% connection, so I'll tinker with getting it up higher and see if anything improves. Thanks in advance for any advice/help.
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:256] open(): Opening media file with object id 409
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:381] open(): path: /data1/30.Rock.S01E04.HDTV.XviD-XOR.ps3.mp4
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:394] open(): fetching resource id 0
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:429] open(): Adding content disposition header: Content-Disposition: attachment; filename="30.Rock.S01E04.HDTV.XviD-XOR.ps3.mp4"
2007-07-14 09:56:49 DEBUG: [../src/web_callbacks.cc:69] create_request_handler(): Filename: /content/media/object_id=409&res_id=0&ext=.mp4, Path: (null)
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:232] open(): start
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:246] open(): full url (filename): /content/media/object_id=409&res_id=0&ext=.mp4, url_path: /content/media, parameters: object_id=409&res_id=0&ext=.mp4
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:256] open(): Opening media file with object id 409
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:381] open(): path: /data1/30.Rock.S01E04.HDTV.XviD-XOR.ps3.mp4
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:394] open(): fetching resource id 0
2007-07-14 09:56:49 DEBUG: [../src/file_request_handler.cc:429] open(): Adding content disposition header: Content-Disposition: attachment; filename="30.Rock.S01E04.HDTV.XviD-XOR.ps3.mp4"
2007-07-14 09:56:54 DEBUG: [../src/web_callbacks.cc:69] create_request_handler(): Filename: /content/media/object_id=409&res_id=0&ext=.mp4, Path: (null)
2007-07-14 09:56:54 DEBUG: [../src/file_request_handler.cc:232] open(): start
2007-07-14 09:56:54 DEBUG: [../src/file_request_handler.cc:246] open(): full url (filename): /content/media/object_id=409&res_id=0&ext=.mp4, url_path: /content/media, parameters: object_id=409&res_id=0&ext=.mp4
2007-07-14 09:56:54 DEBUG: [../src/file_request_handler.cc:256] open(): Opening media file with object id 409
2007-07-14 09:56:54 DEBUG: [../src/file_request_handler.cc:381] open(): path: /data1/30.Rock.S01E04.HDTV.XviD-XOR.ps3.mp4
2007-07-14 09:56:54 DEBUG: [../src/file_request_handler.cc:394] open(): fetching resource id 0
2007-07-14 09:56:54 DEBUG: [../src/file_request_handler.cc:429] open(): Adding content disposition header: Content-Disposition: attachment; filename="30.Rock.S01E04.HDTV.XviD-XOR.ps3.mp4"
2007-07-14 09:56:56 DEBUG: [../src/web_callbacks.cc:69] create_request_handler(): Filename: /content/media/object_id=409&res_id=0&ext=.mp4, Path: (null)
2007-07-14 09:56:56 DEBUG: [../src/file_request_handler.cc:232] open(): start
2007-07-14 09:56:56 DEBUG: [../src/file_request_handler.cc:246] open(): full url (filename): /content/media/object_id=409&res_id=0&ext=.mp4, url_path: /content/media, parameters: object_id=409&res_id=0&ext=.mp4
2007-07-14 09:56:56 DEBUG: [../src/file_request_handler.cc:256] open(): Opening media file with object id 409
2007-07-14 09:56:56 DEBUG: [../src/file_request_handler.cc:381] open(): path: /data1/30.Rock.S01E04.HDTV.XviD-XOR.ps3.mp4
2007-07-14 09:56:56 DEBUG: [../src/file_request_handler.cc:394] open(): fetching resource id 0
2007-07-14 09:56:56 DEBUG: [../src/file_request_handler.cc:429] open(): Adding content disposition header: Content-Disposition: attachment; filename="30.Rock.S01E04.HDTV.XviD-XOR.ps3.mp4"
Sorry, I see the post with the trunk build now.
Yep.. btw you can try 0.10.0 now, the special option to enable the workaround is there.
Yes Jin, the version I'm using is .10 and my problem seems pretty much independent of whatever I make the retry parameter. Regardless of whether it's a small (3) or large (50) value the error I describe arises, although I haven't seen a full system freeze in a while the view times seem to be diminishing and I'm not sure why. I've upgraded my wireless router's firmware and am now seeing a better connection, but like I said the problem still persists. Please let me know if there are any log entries you'd like to see or any clues I can give you as to why this is happening. Thank you.
Tinkered with it more today to no avail. The only difference having the retry parameter seems to make is that rather than lock up my ps3, the file will report as corrupted data instead. My router is reporting the wireless connection to the ps3 as stable and the entire video file is only 78M so I don't think that would be the source of the problem. I wish I could provide more info, but any of the changes I've made seem to have little to no impact, other than restarting the mediatomb server seems hold off the errors for 4-5min.
Also, when the video does create a lockup situation the viewer page for mediatomb manages to lock up firefox as well until the process is killed.
Well, then it is possible that you do not have the problem, for which this workaround parameter was created; maybe your problem is somewhere else...
A wireshark log could give us some clues, however I will be able to look at it next week when I return from holidays (my internet access here is rather limited)
I cannot stream my files for more than 1 minute I get connection to server lost and I am streaming via wired network.
Can you download the file from the server using wget? This would be the first test if largefile works at all.
You can simply copy the link to the item from the web UI, don't forget to put it in "quotes" in the shell
Second test would be to stream that file from MediaTomb using mplayer, just feed mplayer the same link as you used for testing with wget.
If that works, the problem will mostprobably be on the PS3 side, if that does not work we can start debugging.
I did a test with an 8GB DVD iso and mplayer was able to stream it without problems.