Android App: Phoenix for SageTV

[mkanet]

Actually, it looks like it was unset (not associated with any media player) all the way up until just today. I only recently associated it with MXPlayer and other Media players. I did revert back to unset state. Which, no surprise, did the same thing. This tells me that the streamed media doesnt even touch the phone (so it can prompt me which player to use).

It looks like the playlist and the .ts media files are created after each time I select the video profile type. But, for whatever reason dont make it to my phone. If it is a timing issue, the timing/behavior is 100% consistent every time in the same manner. Files are written to my fast SSD drive using a quadcore CPU with 8GB ram. The PC isn't doing anything except for the task.

Originally Posted by stuckless

It might be a timing issue, not sure... I don't set a "default" player, so I prompted to choose a player which takes an extra second or so... the server only waits until vlc creats the html file... may be it hasn't finished "writing" the file before your player tries to read the stream. Can you unset a default player, so that you give yourself extra time and see if that makes a difference... if so, then I can look at updating the server to wait a little long after the file is created.

[stuckless]

Originally Posted by drewg

Ugh. This just got a lot less interesting for me. Drat..

Sorry you wasted your time... I should have clearly stated the limitations in the app description (although I do say it's experimental... i don't actually say what streaming features work)

FWIW, using the plex transcoder & the plex xbmc app setup to use mxplayer to play the video, it looks like Plex transcodes using similar formats (same m3u8), and yet it is seekable in mxplayer. Mxplayer shows the entire show length on the timeline for plex/xbmc, but shows nothing for your sage app. One thing I noticed was that if I snoop the network, I see 2 differences in the extm3u file. One is that that plex generates a complete extm3u file (eg, all the chunks are there). Where the sage app generates an incomplete extm3u file, where the chunks seem to appear as they are transcoded. Also, the header format seems a bit different. eg:
Plex:

#EXTM3U
#EXT-X-TARGETDURATION:4
#EXT-X-ALLOW-CACHE:NO
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:4, nodesc
00000.ts
#EXTINF:4, nodesc
00001.ts
<...>

Sageapp:

#EXTM3U
#EXT-X-TARGETDURATION:5
#EXT-X-MEDIA-SEQUENCE:1
#EXTINF:5,
http://192.168.200.2:8080/sagex/streaming/files/fba139ca-7481-3c19-8184-244b9e49a352/3876863-00000001.ts
#EXTINF:5,

Drew

Does the plex app transcode on the fly? If not, then I can see how that would work, since they would have all parts of the file at the any time. In the vlc solution, the parts are being created on the fly, and the process is linear, so if you wanted to skip ahead 30 minutes, you'd still have to wait for all those sections leading up to the 30min mark to get created.

Again, I intend to look into this, but the poll will determine the next course of action for the App.

Originally Posted by mkanet

It looks like the playlist and the .ts media files are created after each time I select the video profile type. But, for whatever reason dont make it to my phone. If it is a timing issue, the timing/behavior is 100% consistent every time in the same manner. Files are written to my fast SSD drive using a quadcore CPU with 8GB ram. The PC isn't doing anything except for the task.

in you device directory, are there .ts files and a m3u8 file? if so, post the contents of the m4u8 file.

[mkanet]

Stuckless, check your mail.

Originally Posted by stuckless

...in you device directory, are there .ts files and a m3u8 file? if so, post the contents of the m4u8 file.

[Fuzzy]

Originally Posted by stuckless

Sorry you wasted your time... I should have clearly stated the limitations in the app description (although I do say it's experimental... i don't actually say what streaming features work)



Does the plex app transcode on the fly? If not, then I can see how that would work, since they would have all parts of the file at the any time. In the vlc solution, the parts are being created on the fly, and the process is linear, so if you wanted to skip ahead 30 minutes, you'd still have to wait for all those sections leading up to the 30min mark to get created.

Again, I intend to look into this, but the poll will determine the next course of action for the App.



in you device directory, are there .ts files and a m3u8 file? if so, post the contents of the m4u8 file.

I'm pretty sure plex DOES encode on the fly, that's kind of the advantage of the HTML live streaming system, is that it SHOULD be able to pick up mid-stream. I just don't think the VLC encoder is featured enough to do that. Ideally, the server should be able to create the m3u8 file, including http links to each segment of the transcode, even if those other segments of the encode haven't been created yet - it then takes launching the transcode for just that segment when a request comes in for it from the player (or, of course, if it is already transcoded, it could just serve up the pre-transcoded chunk).

It takes a transcoder that can be told a start and stop timestamp for the input file, so that it can pick up wherever necessary. I don't know if VLC can do this, but I'm betting ffmpeg could be made to function in this way with enough 'wrapping' - and the hooks in the http server itself.

[stuckless]

Originally Posted by Fuzzy

I'm pretty sure plex DOES encode on the fly, that's kind of the advantage of the HTML live streaming system, is that it SHOULD be able to pick up mid-stream. I just don't think the VLC encoder is featured enough to do that. Ideally, the server should be able to create the m3u8 file, including http links to each segment of the transcode, even if those other segments of the encode haven't been created yet - it then takes launching the transcode for just that segment when a request comes in for it from the player (or, of course, if it is already transcoded, it could just serve up the pre-transcoded chunk).

It takes a transcoder that can be told a start and stop timestamp for the input file, so that it can pick up wherever necessary. I don't know if VLC can do this, but I'm betting ffmpeg could be made to function in this way with enough 'wrapping' - and the hooks in the http server itself.

I'm pretty sure that's what the current mobile streaming server (jreichen's server) does already using ffmpeg.

My goal (and still is) was to NOT write a streaming server but rather enable VLC to pass through to the client. If all this can be done by passing setting to the vlc process, then Im all in... if not, then I have no intentions on writing a full fledged streaming server

I do plan on playing around with the VLC remote apis (again just control and pass through) but that requires using rtsp instead of hls, which isn't a big deal since the native player and mxplayer both sopport that... but using this, the stream position can be manipulated in real time, so it's a contender for seeking, etc.

My only reason for creating this vlc addition was because when I put the app on my son's phone, he wanted to stream movies, and the existing mobile streaming server didn't work well. Most of our stuff streamed using the RAW transfer method, but some files didn't. Now everything streams, so he's happy

btw... in the next phoenix build, I'll be enabling the "custom" script for vlc... this should enable people to play around with other features of VLC independently of my goals... while using the phoenix streaming server to control vlc start/stop.

[mkanet]

I know this may go without saying for some people; but, its not so obvious to me...

Why cant the Phoenix Android app just use the same FFmpeg-->mplayer mechanism that SageTV Placeshifter uses? There's already FFmpeg encoder (version SNV-r93) sitting in the sageTV server directory; aka SageTVTranscoder.exe

BTW: The newer ffmpeg encoder now support GPU acceleration. Splashtop, which uses the ffmpeg encoder uses almost no CPU power for encoding on my server. I have a $110 GT640 Keplar based Nvidia card makes GPU accelerated HD H.264 encoding a breeze. Im not sure if VLC transcoding takes advantage of this or not.

Originally Posted by stuckless

I'm pretty sure that's what the current mobile streaming server (jreichen's server) does already using ffmpeg.

My goal (and still is) was to NOT write a streaming server but rather enable VLC to pass through to the client. If all this can be done by passing setting to the vlc process, then Im all in... if not, then I have no intentions on writing a full fledged streaming server

I do plan on playing around with the VLC remote apis (again just control and pass through) but that requires using rtsp instead of hls, which isn't a big deal since the native player and mxplayer both sopport that... but using this, the stream position can be manipulated in real time, so it's a contender for seeking, etc.

My only reason for creating this vlc addition was because when I put the app on my son's phone, he wanted to stream movies, and the existing mobile streaming server didn't work well. Most of our stuff streamed using the RAW transfer method, but some files didn't. Now everything streams, so he's happy

btw... in the next phoenix build, I'll be enabling the "custom" script for vlc... this should enable people to play around with other features of VLC independently of my goals... while using the phoenix streaming server to control vlc start/stop.

[drewg]

Originally Posted by stuckless

Sorry you wasted your time... I should have clearly stated the limitations in the app description (although I do say it's experimental... i don't actually say what streaming features work)

No problem, I really do appreciate your effort. I hate plex with a passion, and would really prefer your solution.

Originally Posted by stuckless

Does the plex app transcode on the fly? If not, then I can see how that would work, since they would have all parts of the file at the any time. In the vlc solution, the parts are being created on the fly, and the process is linear, so if you wanted to skip ahead 30 minutes, you'd still have to wait for all those sections leading up to the 30min mark to get created.

Yes, plex transcodes on the fly. I think what Fuzzy says is correct: They fill out the entire m3u8. When there is a "skip", they notice that they get an http get request for a segment which has not yet been transcoded, and re-start transcoding from that offset in the original media, thus creating the requested segment.

One thing I want to be clear on: "Skipping" ahead of where the transcoder is would be nice, but I would consider it to be less critical than being able to ffwd/rewind through whatever has already been transcoded. At least on my machine (a xeon equiv of a core i5), the "wifi_hd" profile transcodes at 2x to 4x the playback speed, so being able to skip through commercials would be possible, and I think that is what most people are after.

I just want to make sure you realize I'm appreciative of your work, and I don't mean to criticize, or make you feel bad or anything. What you have is pretty awesome.

Drew

[stuckless]

Originally Posted by mkanet

I know this may go without saying for some people; but, its not so obvious to me...

Why cant the Phoenix Android app just use the same FFmpeg-->mplayer mechanism that SageTV Placeshifter uses? There's already FFmpeg encoder (version SNV-r93) sitting in the sageTV server directory; aka SageTVTranscoder.exe

I'm not sure I can explain it any better than this... so I'll just post this...

http://xkcd.com/1172/

Originally Posted by drewg

One thing I want to be clear on: "Skipping" ahead of where the transcoder is would be nice, but I would consider it to be less critical than being able to ffwd/rewind through whatever has already been transcoded. At least on my machine (a xeon equiv of a core i5), the "wifi_hd" profile transcodes at 2x to 4x the playback speed, so being able to skip through commercials would be possible, and I think that is what most people are after.

I just want to make sure you realize I'm appreciative of your work, and I don't mean to criticize, or make you feel bad or anything. What you have is pretty awesome.

There is certainly lots of work to do here... in terms of investigating... I will play around with various solutions, and see what happens. Sadly I don't think there is any "magic formula" here... I'm sure that no matter what I build, (using vlc or whatever), it's not going to work for everyone The enture VLC streaming was put together over a few hours on a weekend. Originally, I wasn't even going to share it, since it's primary focus was to simply enable my son to watch movies

[mkanet]

Thanks Stuckless. BTW: I'm able to to fully utilize all features now; including VLC transcoding. I also changed the VLC settings for 2 channel audio. Everything works great now.

For the record, I resolved my issue by using http instead of https (thanks to stuckless for the tip). My jetty server uses a self-signed SSL cert as well as running https on a TCP port different than 443; which MXplayer didnt like.

[Fonceur]

Originally Posted by mkanet

Why cant the Phoenix Android app just use the same FFmpeg-->mplayer mechanism that SageTV Placeshifter uses?

I asked something along those lines to Narflex in June 2010...

Originally Posted by Fonceur

Any chance that you could expose the streaming API used for the placeshifter? This way third party developers wouldn't have to rely on vlc to stream videos...

Of course this is assuming that a regular stream (that could be picked up by most media players) is being sent, and not some optimized/proprietary stream...

Originally Posted by Narflex

this is part of a proprietary protocol we use so there isn't really anything we could open up that'd be of use

[Fuzzy]

Originally Posted by Fonceur

I asked something along those lines to Narflex in June 2010...

It's not really all that proprietary - in that you can plainly see the SageTVTranscoder side of the house, via the publicly available source-code, and possibly reverse engineer the client end - however, that would require actually writing a compatible client for the android/iOS end - which is a LOT harder than leveraging the many already built HLS playback systems.

[HuMan321]

Hi, I am having an issue with this app when testing the connection. This part of the app worked until the Java 7 check part came along. I udpated my WHS machine to Java 1.7x (latest) and had to rename the jre folder in the sage folder and restart to get Sage to see the change.
It now recognizes me as "passing" the Jave test, but it states that it fails on sagex-services installed. I checked and this plug-in is installed and has been.

Another WHS issue? Any help would be appreciated.

[stuckless]

Originally Posted by HuMan321

Hi, I am having an issue with this app when testing the connection. This part of the app worked until the Java 7 check part came along. I udpated my WHS machine to Java 1.7x (latest) and had to rename the jre folder in the sage folder and restart to get Sage to see the change.
It now recognizes me as "passing" the Jave test, but it states that it fails on sagex-services installed. I checked and this plug-in is installed and has been.

Another WHS issue? Any help would be appreciated.

Even though this "fails" have you tried to connect to the server? This test checks the list of installed plugins on the server and verifies if the sagex-services is installed. You could try removing the Sage Remote API Services and then reinstalling it.

[HuMan321]

yes - it connects and the SageTV information is current and correct. All 4 views fail to show any recordings though so I cannot long press one to test streaming.
MobileWeb works fine and shows recordings.

Edit:
SJQ is dependant on the sagex services so I am hopeful there is another reason. I do not want to have to rebuild rulesets/etc...

[stuckless]

Originally Posted by HuMan321

yes - it connects and the SageTV information is current and correct. All 4 views fail to show any recordings though so I cannot long press one to test streaming.
MobileWeb works fine and shows recordings.

Edit:
SJQ is dependant on the sagex services so I am hopeful there is another reason. I do not want to have to rebuild rulesets/etc...

In the failure message for sagex service what is the message beside the failed status. Plugins fail either because they are not installed, or they are not at the right version. Which part is it complaining about for you?

Also, when you installed sagex services plugin were you on a "client" or extender/placeshifter. If you were on a client, then maybe it's not actually installed on the server, but rather, on a local windows client.

[HuMan321]

It says during the connection test Plugin not installed.
This worked for me early on and loaded my recordings until (I think) the checks were put in the connection test.
Mobile web loads everything perfect. Just no recordings in the base app.

It says no media - server did not return any items when I choose any of the four view selections.

The view portion of the app is accurate in stating what is recording next, how much free space etc.

I loaded all plugins etc from WHS server itself

One thing I do not understand is it shows connected to client at /127.0.0.1:1077
Where I do not know where it chose that port number? Maybe nothing, but I thought I would list. This shows in upper right corner of app and I am using port 8080 which is setup correctly in the setting

[stuckless]

Originally Posted by HuMan321

This worked for me early on and loaded my recordings until (I think) the checks were put in the connection test.

Just so you know... the "test" are nothing more than tests. ie, they just let you know what is functioning.

That particular test gets a list of all the server plugins installed (ie, plugins that installed on the server, and start when the server starts, and installed via a placeshifter or extender), and it simple checks if the plugin name is in the list. In your case it is reporting it is not... but even if the app is wrong, then, then it won't affect the rest of the app, since the test justs checks a name in a list and doesn't "turn" anything off if the test fails.

I'm not sure if this is a WHS thing or not.

[HuMan321]

OK- thank you for your support.

Can you tell me if there is any troubleshooting or configuring of the 4 "views" categories on the main screen? Up top the SageTV information is current and correct so it "is" connected.

In the Views section below I have 4 "default" sections (Recently Imported, Recently Recorded, Scheduled Recordings, TV Shows)
If I select any of these it comes back stating "No Media" and Server did not return any items.

This used to populate with my recordings and now does not.

If I go to settings and chose Mobile Web it connects just fine and shows my recording in the recordings area.

My hopes are that it is a permissions issue or a configuration issue, but I don't know where to start.


Is there anything to the client it connects to being port 1077? Whether I connect internally over wireless network or go though outer IP it says the client it connects to is /127.0.0.1:1077. I have not opened any 1077 port and come in through 8080 in the initial server settings that you populate at the beginning.

[stuckless]

Originally Posted by HuMan321

Can you tell me if there is any troubleshooting or configuring of the 4 "views" categories on the main screen? Up top the SageTV information is current and correct so it "is" connected.

There is no configuring required for the views to "work". ie, if all the connection tests are OK, then it means from the App's perspective it has validated that it can authenticate, communicate, etc. I think the root of your issue is the fact that the the sagex services don't appear to be installed (even though you are sure it is )

In the Views section below I have 4 "default" sections (Recently Imported, Recently Recorded, Scheduled Recordings, TV Shows)
If I select any of these it comes back stating "No Media" and Server did not return any items.

This would be normal, if the app can't really communicate with the server.

Is there anything to the client it connects to being port 1077? Whether I connect internally over wireless network or go though outer IP it says the client it connects to is /127.0.0.1:1077. I have not opened any 1077 port and come in through 8080 in the initial server settings that you populate at the beginning.

So the app connects to a SageTV server (which is the server that is setup in the initial step). Once connected to the server, the App "connects" to a "client" that is connected to the server. ie, connecting as a "client" enables the app to do things like "Play on TV". So that "Client Connection" that you seeing is the SageTV client context that this App is representing.

So, the next steps for you would be to...
1. Check the sagetv_0.txt log file, the sagex-api.log and the phoenix.log files for any errors (or zip and and post them/email them to me)
2. You can enable logging to a file on the for the app as well. So, in the app, go to setting and enable log to file. Then kill the app process and start it again (You an do this form the Applications section in Android). Now when the app starts it will start loging to a file on the root of the sd card (ends in .txt).

Then go through the process of test connection and trying to load a view from the main menu, and then send the log file that is generated to me.

[HuMan321]

sagex-api.log

2013-03-06 18:55:05,250 [AWT-EventQueue-0] INFO  sagex.SageAPI - Sage Provider Implementation: sagex.remote.EmbeddedSageAPIProvider; sage://embedded
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             2013-03-06 18:57:16,578 [22309351@qtp-14471018-8] INFO  sagex.remote.SagexServlet - Sage Remote API Servlet for Jetty is loaded.
2013-03-06 19:00:49,250 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:00:49,250 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:05:28,859 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:05:28,859 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:05:41,703 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:05:41,703 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:05:52,140 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:05:52,140 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:05:58,593 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:05:58,593 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:06:29,750 [Thread-13] INFO  sagex.remote.rmi.SageRMIServer - Received Discovery Request: Discover SageTV Remote API Server
2013-03-06 19:06:48,703 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:06:48,703 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:06:49,093 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:06:49,093 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:08:06,546 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:08:06,546 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:08:06,937 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:08:06,937 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:08:37,328 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:08:37,328 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:08:59,609 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:08:59,609 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:09:41,031 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:09:41,031 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:10:40,609 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:10:40,609 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:11:50,328 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:11:50,328 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:13:18,843 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:13:18,859 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:15:02,468 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:15:02,468 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:15:02,859 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:15:02,859 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:24:30,750 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:24:30,750 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:25:04,078 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:25:04,078 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:31:23,359 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:32:45,375 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:32:45,781 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:56:31,734 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 19:56:57,703 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 20:31:45,421 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 20:32:43,906 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 20:32:49,703 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 20:35:37,062 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 20:36:20,078 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 20:36:55,906 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 20:37:56,531 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 21:03:27,562 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 21:05:46,328 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 21:06:24,515 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 21:08:51,453 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 21:09:08,234 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 21:17:17,312 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-06 21:18:35,640 [16824769@qtp-14471018-6] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-07 09:01:57,276 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-07 09:03:01,135 [3808731@qtp-14471018-0] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-07 09:03:01,526 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-07 09:05:20,557 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date
2013-03-07 09:07:03,370 [22309351@qtp-14471018-8] WARN  sagex.util.TypesUtil - Failed to convert  to a valid date